Inconsistent CMIS Query Results? It’s not You, It’s your Locale.

A simple CMIS query like:

SELECT D.* FROM cmis:document AS D WHERE D.cmis:name LIKE '%Flower%' OR D.cmis:contentStreamFileName LIKE '%Flower%'

was giving me a fit lately, not working at all in RightsPro‘s CMIS plugin which uses OpenCMIS and yielding inconsistent results in CMIS Workbench where re-posting the same query ten times would give the expected result maybe half the time.

Thanks to Florian Müller and this post, it seems as though Alfresco doesn’t always behave as expected when the locale is set in the CMIS session.

Removing the locale session parameters got things working in RightsPro, but I didn’t immediately see an easy way to change the locale in a Workbench session (the log shows that it’s using a default of en_US), and I still don’t know what’s up with the inconsistent results there, perhaps a coincidental caching issue.

This was all using OpenCMIS 0.3 against Alfresco Enterprise 3.3.1 over SSL.

MyFaces Tomahawk and the HTML BASE Tag

This one incited a bit of facepalm.

When trying to changing part of RightsPro‘s header implementation to use the HTML BASE tag the element seemed to be ignored completely and resource references were still relative to the page URL. The tag was present, correct, and closed, but having no affect.

It turns out the BASE tag must appear ‘before any element that refers to an external source’ but MyFaces Tomahawk adds any script references needed immediately after the opening HEAD tag, rendering the BASE tag useless.

I don’t have time to modify the Tomahawk source at the moment for a proper fix but did submit a bug.

As a workaround you can put the BASE tag above the head element. It’s not valid HTML but most browsers will still obey it and render the page properly.

A short post, but it may save a few precious hairs from being pulled out. I’ll update if and when the bug is resolved.

Spring @Configurable With AJDT Compile-Time Weaving

I know, that’s a honey of a title, but you found this didn’t you?

Anyways, after some house cleaning and re-organizing of the projects that make up RightsPro in Eclipse I found that domain objects annotated with Spring’s @Configurable annotation were no longer having their dependencies injected when running the app in tomcat or when running AbstractTransactionalDataSourceSpringContextTests unit tests.

Turns out I must have removed the AspectJ library during re-organization and added it back in which also seemed to wipe out the AspectJ Build settings in the project properties. When AspectJ does its compile-time weaving it doesn’t know anything about the @Configurable annotation unless you add spring-aspects.jar to the Aspect Path tab in the AspectJ Build settings.

F yeah, magical aspects are back in business.