Details
-
Type: Improvement
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: EE-3.0.0.GA
-
Fix Version/s: None
-
Component/s: Release
-
Labels:None
-
Environment:EAR deployments
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration
-
Workaround Exists:Yes
-
Workaround Description:Include all required ICEfaces libraries inside the WEB-INF/lib directory of each .war.
Description
A few of our libraries (notably icepush.jar and icefaces.jar) include TLD files where listeners are registered. The current problem is that the listeners defined in these files aren't called when the .jar files are deployed to the .ear as shared libraries in the lib or APP-INF/lib directory of the .ear file. This is an issue for some deployment scenarios where the developer would rather include a single copy of the library to be shared across several .war modules.
Issue Links
- blocks
-
PUSH-173 ICEpush EE 3.0.0.GA - NPE on org.icepush.util.ExtensionRegistry.getBestExtension
- Closed
One possible solution would be to create an icesoft-tld.jar that contains all of our .tld files and simply include that in each .war. Then the tld files would get scanned and, as long as the required libraries were on the classpath, the required listeners would get called.
This is a bit theoretical at this point and would need to be tested before proceeding as a final solution. There may be a problem including a .jar that has all of our tlds if someone isn't using a specific feature. For example, if an application doesn't need icepush.jar and doesn't have it isn't installed, what's the impact of still calling the listeners?
Also, to officially support this, it would be necessary to implement our listeners so that they could detect being initialized multiple times.
If all of the above testing proved this out, we'd need to:
• Audit all our libs and create an icesoft-tld.jar that has a collection of all the tld files from the relevant libs (at least icepush and icefaces at this point, not sure about ace, compat, composite, accessible, etc yet) that could be deployed in each war.
• Create build tasks to reliably build the new .jar.
• Provide documentation on how and when to use the technique.