Community
Participate
Working Groups
This is just a 3.0 target for https://bugs.eclipse.org/bugs/show_bug.cgi?id=222531 If you want to mark this as a duplicate I suppose that's fine, but I'm providing a patch for HEAD and I thought it did not belong in a bug titled Regression (?) between wtp 2.0.1 and 2.0.2 in J2EEFlexProjDeployable ------ I recognize I've been very prolific in writing on the other bug and it might be hard to separate my valuable comments from the rest. Let me try to summarize the issues that still remain here. The setup: A generic .jar resource is added to "module" tags in an EAR's application.xml. It is then ignored entirely during publishing and in parts of the Virtual Component Model's intersection with the wst.server API's. It is not returned as a child module for reasons I will explain. It is also not returned from the members() method of the EarVirtualRootFolder *** 3.0 stream *** In the 3.0 stream, anything mentioned in the application.xml inside a module tag is treated as a Reference, specifically a "loose reference" in the EarVirtualComponent class. It achieves this status because on line 154 of EarVirtualComponent, the EarVirtualRootFolder is asked if the component is dynamic: if(folder.isDynamicComponent((IVirtualFile)members[i])){ [EarVirtualRootFolder:154] and the EarVirtualRootFolder discriminates *solely* on the extension of the resource. [EarVirtualRootFolder 42-50] With the resource's new found status as a "loose reference", it is *expected* it would be returned as a child module and not as a member. The reason it is *not* returned as a child module is made clear in JEEDeployableFactory: 113-120 [see comment 49], which found the archive's type to be JavaEEQuickPeek.UNKNOWN and so skipped it as a child module. This is fair, because the factory is now promising to treat this unknown-type jar as a member and not a child module. Later on, in the members() method of the J2EEFlexProjDeployable, it will ask whether it should include these utility jars as members or not. The members() method will try to prune out those which should already be child modules and preserve only those which were ignored earlier. The sole way it will discriminate is whether or not the jar is mentioned in the EAR's deployment descriptor, application.xml. This ultimately is where the problem lies. The JEEDeployableFactory ignored the jar because it had a type of JavaEEQuickPeek.UNKNOWN and could not make a child module out of it. On the other hand, members() is now ignoring it because it was in the deployment descriptor at all! I've got a small patch to the 3.0 HEAD branch to J2EEFlexProjDeployable.isNestedJ2EEModule (called by shouldIncludeUtilityComponent) which will change from just checking whether the jar is mentioned in the DD, but *also* that it has a discernable type and was *not* passed over by the factory as a child module. This will ensure that even in those cases where a user adds module tags where they don't belong, or if a jar is misidentified, or whatever the case, *none* of the resources will be ignored. All will either be handled as a child module, or as a member. I feel this is a good patch and I hope you all to approve it.
Created attachment 95777 [details] Example Project demonstrating the failure This is a project with one resource (other than the relevent xml files), a jar library, which is added in module tags in the application.xml. In HEAD, the jar is ignored, both from getting the children modules of the EAR project, as well as from the members() method.
Created attachment 95778 [details] A patch for the problem This patch will make sure that, when checking whether or not to add a jar to the members() list, it checks not only whether it is in the deployment descriptor, but also that it's type is known. The reason this needs to be done is because the JEEDeployableFactory ignores any module which has type UNKNOWN, and to compensate for that, the resource must still be published in some fashion. The members() method *is* that fashion.
Carl can you please take a look? Please work with Rob applying this patch, and also help verifying on 202 stream for https://bugs.eclipse.org/bugs/show_bug.cgi?id=222531
I'm adding a hotbug request so this issue does not go unnoticed before release.
I've downgraded the bug that brought about this bug... specifically https://bugs.eclipse.org/bugs/show_bug.cgi?id=225012. It became apparent that our projects were using the application.xml incorrectly. However I'm leaving this opened here because I think it's important that application servers be allowed to extend the spec and allow module types that hte tools might not be prepared for, Because there's already a patch here, and because I would very much like to see it in the 3.0 release. I downgraded the other because it is unreasonable to expect new features in a maintenance stream. I believe this bug is still 'hot' ;)
This looks like a good patch. Accepted as a hotbug. (Apologize for the delay, but I have been busy w/ both the WTP 3.0 M7 DCUT and other work responsibilities.)
Since Chuck is on vacation & left me as a reviewer, I have reviewed this change and approve of it getting into M7. Committed to HEAD.
mass change to add 'contributed' keyword based on bugzilla query, please correct if that's not accurate (by marking patches as obsolete and removing the 'contributed' keyword.
