Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Definition of child modules (specially binary) and members during deployment
On 04/30/2015 04:07 PM, Roberto Sanchez Herrera/Mexico/IBM wrote:


Parent Module type                Reference                        Member or Child module
EAR                        WAR, EJB jar with DD, rar                Child module
EAR                        utility jar        , EJB jar without DD                Member
WAR                        Web fragment, EJB jar with DD                Child module
WAR                        utility jar        , EJB jar without DD                Member


A utility jar is not a "module" as per JEE, so it honestly never should be a child module. The problem is that there's no other way to express to server adapters that they need to 'zip' up a Utility project other than to mark it as a child module.

The difference between EJB jar with DD vs EJB jar without DD is (as I understand it) primarily a performance issue. IT is very easy to scan a jar to see if there's a DD in it and thus identify the jar as a child module or not. It is much more resource intensive to scan the jar for annotations or other such metadata. So an EJB jar without DD is treated the same as a utility jar.

I honestly think it'd make more sense to develop a cache of these jars with full scans to determine if they're modules or not, with the result cached (and updated) based on timestamp. ie, if the underlying .jar changes, you would re-scan the jar to determine if it's a member jar or an ejb module.

2. For bug 439685  [1], should the reference to the web fragment jar be considered a member? Or should remain as child module, and the server adapters have the responsibility of handling them properly?

After reading some of the explanations on web fragments, I genuinely believe web fragments are child modules, and all server adapters (including the preview servers) should be prepared to handle the nesting of modules, or remove their support for web fragments, which are by their nature child modules.


3. Should we document this somewhere?


It's kinda hard to document a mix of inefficiencies and slight changes due to happenstance and history. At this point, such documentation would basically be as follows:

"Sub-Projects are always child modules, even when they're not JEE modules, because the API does not allow any other way for servers to know they need to zip up a project.   For archives, do your best to determine if its a child module, but take care of performance since these methods may be called often. When in doubt, marking an archive as a member is safer, but it won't show up in the Servers view as a child module, and some server adapters will lose the ability to control those child modules' states via start / stop / restarting the child module."

Those are my thoughts. Not sure if anyone else agrees.

- Rob Stryker

Your comments are welcome, specially if you put them on the bug 439685  [1]

Thanks.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439685
[2]  https://bugs.eclipse.org/bugs/show_bug.cgi?id=439685#c8
Regards,

Roberto Sanchez Herrera
 

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top