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.
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.