I'm in the process of implementing the CDI support for GenericPortlet and would
everyone's thoughts on how the changes in gatein-pc should be integrated into
gatein-portal.
The changes in gatein-pc are purely around lifecycle modifications and enhancements, and
don't entail anything CDI specific within them.
However, gatein-portal/component/pc is modified to add the listener to perform CDI
injection within ExoPortletApplicationDeployer, and the code for the listener brings with
it the need for CDI on the classpath of the module.
My current thinking is to create a gatein-portal/component/cdi module that contains the
listener code, with dependencies on CDI, etc. Then in ExoPortletApplicationDeployer I try
to instantiate the listener based on the class name, and do nothing if that fails.
I see the benefit of this being that we don't then have to ensure that each package
option we provide also bundles a CDI implementation, as neither Tomcat or Jetty support
CDI OOTB. So ExoPortletApplicationDeployer can simply not add the listener for CDI when
the class is not present, and whether its present is determined by packaging.
Does that sound ok?
Also, the CDI scope implementations I think are best suited to be in a new repo under
gatein on github, which contains the scopes and the CDI extension to activate them. And
once again the packaging will be updated to include it for only environments that contain
a CDI implementation, such as AS.
Thanks
Ken
========================
Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.