Maven 2 Version

29 03 2007

You may have noticed that the maven 2 build has M2 all over it. This was to avoid conflicts with the maven 1 builds, but we need to be able to build everything to particular versions. This is not quite as easy as with maven 1 where allowed you to build a specific version.

In Maven 2 the mechanism appears to be the settings.xml file, where properties can be defined. At some point I need to change all the M2 references into ${} references and provide a settings.xml file to define what is, alternatively a simple mvn command could be used, eg mvn The drawback with thins is that its not bound to SVN so when you check out the 2.4 tag you have to know howto build. Perhaps a and build.bat would make sense. However we do it we need to be able to build different version bound to SVN without editing the entire pom tree…… but then on release a find sed combination wouldn’t be so bad ? (runs for cover)

Thread Unbind

26 03 2007

ThreadLocalManager does not give the application using it any indication of when the request cycle is over. If it had some unbind mechanism then objects could be notified. eg If the object being ejected from the thread local implement ThreadUnbind, its unbind method is called.

I might have thought this before, it would make it much easier to release resources.

Reimplementing JCR

26 03 2007

I’m having another go at implementing A JCR based service in Sakai, this time I’m not binding it to CHS as I want to see if its possible to solve the clustering issues with Jackrabbit 1.2.3. So far the structure looks interesting, javax.jcr.* lives in shared and with a very small additional API, used can get hold of a JCR session, which my be authenticated as system, anon or a Sakai user. Once they have this they can manipulate the repository using all the normal JCR/JSR-170 API features.

The implementation is a Jackrabbit one, that uses a JAAS based Login Manager and a Custom Secirity manager to connect to Sakai. I am allowing as part of the public API users of the JCRService to rejuster SecurityConverters that convert the pure JCR locks into more meaningful Sakai locks and the pure JCR references into Sakai security realms. This is an inject on init pattern as used by the Portal for its URLHandlers and RenderService Impl.

The Hope is that, with some work it will be possible to run implement other JCRServices using Harvest Road, Xythos, Alfresco or others and it should be possible to bind to these over JCR-RMI allowing Sakai to use an Institutional JCR. When we looked at this in the past the JCR inside CHS had too many bindings that were going to make it hard work to use other JCR’s.

Naturally with the new Content Hosting Handler mechanism in CHS 2.4 it will be possible to write a simple CHH bridge to the JCRService to allow content to be hosted there, although I suspect some new test tools will just bind direct as the JCR API is more powerful and feature rich. Unfortunately its also more difficult to use, so I can see a JCREasyService being created.

Not to write a bundle of Unit tests to stress the system. Perhapse I can just re-user Jackrabbits own test suite with a suitable startup/teardown combination… mocking the cover for UserDirectoryService is going to be fun 🙂

And you thought you had privacy.

21 03 2007

Howe do you go about storing large volumes of data persistently in a browser. Cookies are no good because the data gets sent back to the server so it will break most http connections at about 4K. But there are a number of newer mechanisms appearing. IE5+ has had userData ( ) for a while, Firefox2 has DOM:Storage from the HTML5 spec (see and ) and then there are things like halfnote ( ). We appear to moving rapidly to a state where the browser is becoming an offline client, but none of this works for FF1.5, Safari and others.

Then there is Flash which has local storage, where a site can store upto 100K of data on your machine without the user being asked to confirm, it works everywhere flash works and doesn’t have any of the drawbacks of cookies. The only problem is the calling interface between Javascript is totally insane. You have 2 options, an asynchronous event queue or writing lash tags with parameters into the DOM.

With a footprint of 1px by 1px and 4K who is going to notice it ?

RWiki will be using this for autosave functionality.


21 03 2007

Earlier I had raised the idea that JCR might exist behind RMI potentially in a remote JVM. Once thing I hadn’t considered was the security model. In past implementations of Jackrabbit as a Service in Sakai it was tightly bound and embedded. There is a security manager that uses JAAS to connect to the Sakai Security services (AuthZGroups) and answer role/context based security questions.

If a JCR was to be accessed over RMI, then this model would need to stand, as the JCR would still need to answer fine grained security questions. In a remote environment, we loose some of the efficiencies when answering the security questions directly, however the SercurityManager abstraction in Jackrabbit/JCR would enable us to plug in an implementation suitable for connecting to Sakai. Options include taking a stub of the SakaiFramework with enough support to use the AuthZGroup service through to basing something on Guanxi and an IDP. Bear in mind however that the number of security questions that are answered in the JCR is high and the scope of those questions extremely wide and so direct integration with the SakaiFramework might be the best approach.

The other ugly head that a remote JCR raises is just how the user is identified. We no longer have the request thread from which to gather the current user. We need to provide a securely hashed token that identifies the user logged into Sakai. Naturally this would be part of the JCR session so that when the JAAS implementation was asked to answer a security question it would consult this token to determine which Sakai user was associated with the request.

Why am I even thinking about this…..

Scalability. Just as has recently been done with search, where a search cluster can exist within a Sakai cluster, as a group of compute nodes dedicated to search operations which deliver search results over a REST based web service. A JCR cluster will remove processing load and memory footprint from the front end request based services. There is limited scope at the moment to make the link asynchronous, but it opens the way in the future. JCR-RMI also makes opens the door to make other JCR implementations pluggable as a back end cluster or even to integrate with the future institutional JCR.

Google Just cant help themselves.

21 03 2007

With all that money swimming around in Google they cant help but hire lots of programmers and let the experiment. Recent examples which lets you correlate CO2 tomes per capita to life expectancy and play how it changed over the years. (actually this is flash and it was bought by Google, but it wont be log before it becomes Javascript+HTML+Canvas) and then there is a Canvas emulator to poor old IE browsers but the UI that makes you blink continues to be just right click to see if you can find any flash….. there isn’t any! Java2D for Javascript

Jackrabbit cluster has moved on

21 03 2007

It looks like Jackrabbit clustering has move on quite a bit since I last bought a JCR up. Originally there was a demand for clustering in and later that was implemented under The basic mechanism is to maintain a journal log that all nodes in the cluster subscribe to and replay to remain consistent within the cluster. The replay causes the the nodes in the cluster to maintain their cache consistent with other nodes in the cluster. The transport mechanism of the cluster was originally file system but could be anything

Now in 1.2.3 there is a database backed journal log. Which would make it really easy to implement a JCR cluster…. but perhaps an embedded JCR isnt the way to go as it has a clean RMI interface that will/should be able to connect to any 170 implementation. Offloading all of the content storage to a content storage cluster, separate fro Sakai has some attractions, not least because the API is clean and at a complexity narrow point, leading to network efficiency. Similarly, using the Jackrabbit RMI libraries to connect to a suitably configured JCR server will enable vendors and institutions to plug in a JCR server underneath Sakai without changing Sakai code…. just like Oracle or MySQL.

The other positive, is performance, Jackrabbit appears to be even faster, 380MB in 8,101 files was reporting and ETA of 5 minutes over WebDav to localhost on an OSX box. I wont tell you what the equivalent currently is for Sakai, try for yourself 🙂