(Potential) issues with embedding alfresco

[yujin_kim]

Hello

Our company has looked into the possibility of embedding Alfresco into our product as the content backing store for our CMS front end.

There are several integration issues we have come across that we'd like to share with you and get your thoughts and recommendations. Also, if there are upcoming changes that may affect the integration process, it would be nice to hear about those as well.

   1. Use of Acegi Security: Our product also uses Acegi Security, and there are concerns regarding collisions of the SecurityContext, since the SecurityContext is bound to the thread. This issue has also been brought up on the acegisecurity-dev list, but has received no input thus far.

   2. Version of Acegi security: Alfresco uses 0.8.2 which has an old packaging naming convention, and some significant differences in terms of classes that were renamed or refactored for the 1.0 release. Does Alfresco plan to remain with 0.8.2 for the foreseeable future, or is there already work being done to bring Alfresco current with using the release candidate of 1.0?

   3. Management of patched or updated dependency libraries: Is there a way we can distinguish between which libraries have been patched or customized for use in Alfresco, and which libraries can be simply obtained from their respective repositories?

   4. Dependency Management: There are currently no list of required dependencies and their version numbers for Alfresco. To make Alfresco more third party vendor friendly, is there any plan to update the Alfresco build process to use a dependency management tool such as Maven or Ivy? We have internally already developed a skeleton Maven build desciptor for our internal use, and we would be happy to work with you on that end. (Separate discussion on http://forums.alfresco.com/viewtopic.php?t=1017&highlight=maven)

   5. Integration of configuration files: The concept of using files in the alfresco/extension classpath to override default property values/beans by Alfresco works well when the files are exploded, but if we decided to include Alfresco jars (repository.jar and core.jar), and then an accompanying jar that contains the default configurations (/alfresco) and our custom configurations, then this does not work because the default configuration paths are not wildcarded across all classpaths. So, on startup, Spring only discovers default configurations that are in exploded form in the classpath itself (fails to find it in the configuration.jar we have created.). This means that we have to custom build an alfresco.jar that contains the configurations inside.

Any help you can provide in resolving these issues is greatly appreciated.

Best regards,

Yujin Kim
Vivakos, Inc

[andy]

Hi

In response to 1), 2) and a bit of 3)

1) - There should be no issue with collisions on the security context.
We effectively only get the user name from the context if you uses acegi (or we set this context if using our ldpa, Jaas access). We only expect the base type as defined in acegi. Groups are defined outside of acegi although you could implement groups from acegi if you want. I do not check the acegi dev list.

2) We intend to update Acegi at some point. This work is not underway at the moment.

3) The only altered jar that I know of is our version of lucene-1.4.3

Regards

Andy

[mindthegab]

We're pushing the maven approach also,
that's why we've published (ATM) an archetype for building alfresco customizations here https://forge.alfresco.com/projects/m2alfresco.

When/if also alfresco itself moves to maven, this will be even more useful.

Hoping that, and hoping to help

Ciao!