In JR2, inside the acl.ACLProvider there are protected methods designed to be overridden. You still have to do this inside the same package as the native JR2 classes, in order to instance private internal classes, but at least extending the default ACL resolution in Jackrabbit is a case of extending a few classes. All of this put inside an OSGi environment makes it possible to re bundle an embedded Jackrabbit server with custom extensions on the core… and no need for a massive patch set…. another reason to upgrade to JR2.

Fortunately it looks like all of this has been fixed in Jackrabbit 2. Now the UserManager does not store users in a nested form, it has an autoscaling sharding mechanism and the search query generates results that are far more direct. Some of this is not enabled by default, but here is the config that makes it work.

In repository.xml

<!DOCTYPE Repository 
       PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 2.0//EN"
"http://jackrabbit.apache.org/dtd/repository-2.0.dtd">
<Repository>
     <FileSystem>
        <param name="path" value="${rep.home}/repository"/>
     </FileSystem>
     <Security appName="Jackrabbit">
        <SecurityManager workspaceName="security">
           <UserManager>
             <param name="defaultDepth" value="4" />
             <param name="autoExpandTree" value="true" />
             <param name="autoExpandSize" value="500" />
           </UserManager>
        </SecurityManager>
        <AccessManager>
        </AccessManager>
...

In tests in Sling I see no slowdown in user creation upto 10K node. With HTTP requests ranging from 12-25ms. To add those 10K nodes from a single request thread takes 6m4s, a rate of about 27/s. The same test performed with Sling on Jackrabbit 1.6 was averaging 6/s over 10K nodes. Concurrent add operations tend to speed this up further as the http cost is factored out. My laptop runs out of steam at about 70/s.

User Node paths that are generated are of the form

.../t/te/testuser201003070946420-300

.../t/te/tes/test/testu/testus/testuse/testuser/testuser2/testuser20/testuser201/testuser2010/testuser20100/testuser201003071035370-4998

Although 90% of those that write code for a living don’t do documentation and certainly don’t do it in advance, its far quicker and easier to experiment with ideas in plain English. (oops forgot that should be _i18n_native_tongue_ ), I wont go on, suffice it to say I’ve been trying out spec before implementation and found that on many occasions nuances that I can see would have appeared in the implementation have appeared in the spec, but the cost of correction has been significantly lower and my personal dialect of english has passed my patched english complier most of the time. Other’s substandard copies have problems. The bigest thing I have noticed with this approach is that I haven’t wasted hours debugging what I would eventually throw away.

It’s interesting that the software industry does so little of this. My first vocation in life was a design engineer; mechanical, high vacuum. There was no point in taking a stock bar out of the stores putting it into a lathe and hoping to machine off the right amount to make a stub shaft. In fact with high vacuum and often high voltage that was a positively dangerous pastime. Perhaps 200 years ago at the start of the industrial revolution or today if creating a work of art, but for engineering the physical material is always the last final part of the process. As software engineering, still a young profession evolves perhaps we will see more design and works of art and less metal bashing.

Several years ago, when I was still allowed to do sysadmin, a “joy” I am no longer considered safe to tackle. I was migrating an active CVS repository to a Subversion, the new and better source control system that didn’t force you to lock before edit. Sitting there at my keyboard, trying to get it done before a meeting a developer had taken the enforced downtime to continue that esoterically argument about memory consumption of byte arrays in C++ versus Java with a manager or co-developer, I can’t remember which. “^Rcvs” goes the keyboard, hoping to retrieve ”find . -name ‘*cvs*’ ” for the zillionth time, then as I hit the enter key, I hear something just so outrageous I have to turn around and join in. Meanwhile “rm -rf /repo/cvsmain” poped up from bash history and diligently got to work. Needless to say the developer who’s work was in that repo cornered me at twilight, and I never did sysadmin again. Fortunately there was no period in hospital. If you hate doing sysadmin, thats a sure fire way to get out of it.

There is a reason a Study is called a Study, there the most common utterance spoken in a library is “shhh”. To get complex things into your head takes time free from distractions. The sorry take above was a simple case, and the volume of information very low, but the conversation and level of bullshit so tempting I couldn’t resist it, and bang, I wasn’t thinking what I was doing, my mind was blank and empty, just like the diskspace 5 minutes later, never again will I try to mix bullshit with command line.

So three months ago, I realised that most of my coding and complex work was done after 8 in the evening, or between 5 and 8 in the morning if I could not sleep. Time for an experiment, what will happen to my working hours if I move out and zone in. I upped camp, replugged the IP phone into an empty office down the corridor. By 10 I have cleared email, and loaded my head with everything that was there yesterday. Verified that dementia has not set in, yet, and I find I can get a good hours productive output in before the 15 second question brings it all to a grinding halt for the next hour. I looked at my timesheets last week, yes even in a University we have timesheets, there is no escape; and discovered that since moving to a quiet “study” environment, my hours have dropped from averaging 60+h to a far more reasonable 40h per week. I am almost certain that quality has gone up, I am working on a new version of the Sakai backend, looking at the stats we have resolved close to 500 issues, just did a 0.2 release and have 6 open bugs, with close to 90% test and integration test coverage.

I know plenty of other engineers have reported the same phenomena, often to deaf ears, but I cant help think that the change has something to do with it. So if you manage a mixed team of engineers, creatives try an experiment, create a space for communication but put those that need to study to get the job done in an environment where the most common utterance is “shhh” and let them get on with what was asked. If fall asleep, kick them, but quietly. If it doesn’t work, shout at them, but take them outside first, please.

cd launchpad/testing
mvn clean install
mvn jetty:run 1> run.log 2>&1 &
# wait for startup to finish
mvn test -Dtest=**/integrationtest/**/*Test.java

you can leave the server running, redeploy bundles and re-run specific tests avoiding a full rebuild.

To address this in Sling/Sakai K2 I have just done a first pass at documentation annotations that are discovered at runtime to build a set of documentation for the Service. I say service, because Sling is OSGi based, and every HTTP service end point is implemented as a OSGi service implementing javax.servlet.Servlet. The approach could be used for any service, but I am using it for Sling Servlets.

How to use:

First off, all Servlets that are active in the system are automatically registered with the documentation system, and if any of them don’t contain documentation there are some gentile reminders to the developer to create the documentation. If there are no documentation annotations present there are some friendly defaults.

add the documentation annotations to you build

<dependency>
 <groupId>org.sakaiproject.kernel</groupId>
 <artifactId>org.sakaiproject.kernel.doc</artifactId>
 <version>0.1-SNAPSHOT</version>
</dependency>

So, add some annotations to your class:

@SlingServlet(methods = "GET", paths = "/system/doc")
@ServiceDocumentation(name = "DocumentationServlet", description = "Provides auto documentation of servlets registered with OSGi. Documentation will use the "
 + "service registration properties, or annotations if present."
 + " Requests to this servlet take the form /system/doc?p=&lt;classname&gt where <em>classname</em>"
 + " is the fully qualified name of the class deployed into the OSGi container. If the class is "
 + "not present a 404 will be retruned, if the class is present, it will be interogated to extract "
 + "documentation from the class. In addition to extracting annotation based documention the servlet will "
 + "display the OSGi service properties. All documentation is assumed to be HTML encoded. If the browser is "
 + "directed to <a href=\"/system/doc\" >/system/doc</a> a list of all servlets in the system will be displayed ",
 bindings = @ServiceBinding(type = BindingType.PATH, bindings = "/system/doc"),
 methods = {
 @ServiceMethod(name = "GET",
 description = "GETs to this servlet will produce documentation for the class, " +
 "or an index of all servlets.",
 parameters = @ServiceParameter(name = "p",
 description = "The name of the class to display the documentation for")) })

public class DocumentationServlet extends SlingSafeMethodsServlet {

And then rebuild and reload your Servlet.

Finally browse to http://localhost:8080/system/doc to check the documentation.

Obviously because the documentation is in the code and its deployed with the code, provided the developer keeps it current with the code they are editing, the documentation will be correct. So the next $64K is “How to make developers document what they do ?”

In JcrResourceResolver2.resolveInternal there is a loop that attempts to resolve a URI by selectively stripping off the segments of the last element using a . as a seperator. When a resource resolves the section of the path that resolves is used as the resource path, and the remainder is used as the resource path info. The selectors and extensions are explicitly parsed out of the resource path info ignoring anything that the ResourceProvider might have done. It is therefore vital not to attempt to process a path within a ResourceProvider, as the path used to determine the the resource path and the path info is local to resolveInternal and not influenced by anything that the ResourceProvider might choose to do.

There are one or two special cases. If no resource is found, the last element is processed in its entirety before a NonExistingResource is created and hence anything that gets involved in the ResourceProvider process should be very careful about creating Synthetic resources since unless a convention is followed the resource path cant be determined from the URL alone. Take the example of a virtual resource. Since its virtual and the resolution process is abstract, delayed until after resolution, nothing is known about the ultimate target. The convention we follow is that the last element cant contain ‘.’ I think this is going to cause problem and result in moving the whole resolution process inside the resolveInternal call tree, putting any code in a modified Sling JCR Resource Bundle. Unlike previous attempts this will not require patching the code base, just repackaging, unless I can work out a sensible patch that avoids recursive resolution.

Sorry if that was very boring, as I said in the title Note to self.

AFAICT, an annotation like

@Reference(name="virtualResourceType",
 cardinality = ReferenceCardinality.OPTIONAL_MULTIPLE,
 referenceInterface = VirtualResourceType.class)

with

public void bindVirtualResourceType(VirtualResourceType virtualResourceType) {
    log.info("Bound "+virtualResourceType);
   store.put(virtualResourceType,virtualResourceType);
}
public void unbindVirtualResourceType(VirtualResourceType virtualResourceType) {
   log.info("UnBound "+virtualResourceType);
   store.remove(virtualResourceType);
}

Only binds some of the time on reload, but unbind works every time.

I have a feeling that below will work, no idea why ?

protected void bindVirtualResourceType(ServiceReference reference) {
   VirtualResourceType virtualResourceType =  (VirtualResourceType) this.componentContext.locateService(
       "VirtualResourceType", reference);
   if ( virtualResourceType != null ) {
      LOGGER.info("=====================BOUND VIRTUAL RESOURCE TYPE{}===============================",virtualResourceType.getResourceType());
      virtualResourceTypes.put(virtualResourceType.getResourceType(), virtualResourceType);
   } else {
      LOGGER.info("=====================Faied to find BOUND VIRTUAL RESOURCE TYPE{}===============================",reference);
   }
}

Update:

The annotation should have been

@Reference(name = “virtualResourceType”,
cardinality = ReferenceCardinality.OPTIONAL_MULTIPLE,
referenceInterface = VirtualResourceType.class,
policy = ReferencePolicy.DYNAMIC)

and then the bind and unbind can be

protected void bindVirtualResourceType(VirtualResourceType virtualResourceType) {
    virtualResourceTypes.put(virtualResourceType.getResourceType(), virtualResourceType);
}

protected void unbindVirtualResourceType(VirtualResourceType virtualResourceType) {
    virtualResourceTypes.remove(virtualResourceType.getResourceType());
}

(I am an idiot!)

Go to the admin console, select the configuration tab.

Select from the Configuration Factories drop down the logging.config Factory,

Set the properties including the package or class that you want this logging config to apply to, and save.

As I mentioned, you can do all of this on a running instance, no need to shutdown.