Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: I have custom EAR and EJB projects. The EJB project has reference to the EAR project via module core model. If EJB project is renamed via refactoring, the reference was deleted. This bug occurred because in the UpdateDependentModuleonDeleteOp.updateManifestDependency try to get jar’s list from the manifest.mf contents but in the custom EAR project has no manifest.mf Defect could be reproduce if create 2 Utility Projects: customEar and customEjb. In order to create reference in the project customEar should be insert this: <dependent-module deploy-path="/" handle="module:/resource/customEjb/customEjb"> <dependency-type>uses</dependency-type> </dependent-module> And also should be remove manifest.mf from project customEar After that rename the project customEjb and check that dependent-module was disappear from customEar in the error log appear Exception thrown More information: Exception thrown: org.eclipse.core.commands.ExecutionException: Error reading manifest at org.eclipse.jst.j2ee.refactor.operations.UpdateDependentModuleonDeleteOp.getArchiveManifest(UpdateDependentModuleonDeleteOp.java:140) at org.eclipse.jst.j2ee.refactor.operations.UpdateDependentModuleonDeleteOp.updateManifestDependency(UpdateDependentModuleonDeleteOp.java:116) at org.eclipse.jst.j2ee.refactor.operations.UpdateDependentModuleonDeleteOp.removeModuleDependency(UpdateDependentModuleonDeleteOp.java:98) at org.eclipse.jst.j2ee.refactor.operations.UpdateDependentModuleonRenameOp.execute(UpdateDependentModuleonRenameOp.java:59) at org.eclipse.wst.common.frameworks.internal.datamodel.DataModelPausibleOperationImpl$1.run(DataModelPausibleOperationImpl.java:376) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
Created attachment 56690 [details] Example project to reproduce defect After importing the projects you should just rename the customEjb project in order to reproduce defect.
Created attachment 56691 [details] Check is the manifest.mf exist or not
Hmmm, before accepting this as a hotbug (or a valid bug, actually), I want to explore a bit whether your custom project structure is one that WTP should be officially trying to support: -Note: the "customEar" file is not in fact an EAR project but is recognized by WTP as utility project (i.e. it has the jst.utility facet) and it is expected to have a MANIFEST.MF file; that is why UpdateDependentModuleonDeleteOp is being executed rather than UpdateDependentEAROnDeleteOp (the EAR operation, as expected, does not attempt to process a MANIFEST.MF) -WTP (as of release 1.5) no longer stores the dependency information between module projects in the component file but uses the manifest classpath (that is how the J2EE module dependency UI logic is structured and how the J2EE classpath containers work) -So, the dependency you are representing between "customEar" and "customEjb" is being interpreted as a module project dependency but it is not represented in the correct way (i.e. in the MANIFEST.MF) and therefore the WTP UI support, classpath container support and refactoring support will all not handle the situation correctly. My initial take is that you should not attempt going down the path of representing a EAR project using what is actually a hacked utility project - I think you'll hit a whole host of other issues (another example: your EAR project should not be a Java project but it is in this context) Have you tried using a customized EAR project (i.e. one with the jst.ear facet) so that the EAR-specific operations are executed? Chuck/Jason: thoughts?
I agree with you Robert. This scenario is not (and should not be) supported. Yavor, why do you need to define custom EAR and EJB projects. Is there something missing from the various WTP frameworks preventing you from utilizing the standard EAR and EJB facets?
I'm going to decline this as a hotbug and change the description; I'm happy to work with you to try and find a solution that utilizes the appropriate facet/module identification for the projects (if that just won't work, then we can add checks like you have proposed in the patch but should really think more carefully about how this scenario is best supported; in any event, this is 2.0 work)
Hi Rob, With the attached utility projects I try to give you similar EAR 5 and EJB 3.0 project. Our EAR 5 and EJB 3.0 are faceted projects. We use “jst.new.ear” facet for EAR 5 and “jst.new.ejb” facet for EJB 3.0. In the ProjectRefactorOperation.updateDependentProjects has check is this project refactoring metadata has jst.ear facet or not. In our case this check detected that project is not jst.ear and execute updateDependentModuleProject and treat our EAR 5 project as utility project. The other solution could be if we fix code to recognize not only jst.ear, but the extended ones also.
hi Yavor, Unfortunately, using a custom facet like "jst.new.ear" (if unassociated with the "jst.ear" facet) is not sufficient to allow WTP to correctly recognize your project as an EAR project. You either need to ensure that your custom facet takes a dependency on "jst.ear" (effectively "extending" jst.ear) or simply use the new "5.0" version of the "jst.ear" facet (that should give you the desired behavior).
Hi Rob, We cannot extend jst.ear and jst.ejb with newer versions, because internal checks in WTP code make them behave as old facet versions (see bug 157185). Your statement '...your custom facet takes a dependency on "jst.ear" (effectively "extending" jst.ear)' sounds quite interesting. If we enable both "jst.ear" (version 1.4) and "jst.new.ear" (version 5) facets in our EAR 5 module then I suggest that both install delegates of the facets will be executed. This will cause problems later during runtime. Does this "jst.new.ear effectively extending jst.ear facet" differs from the above? What is the nature of this dependency? Will be the jst.ear install delegate omitted in this case?
(In reply to comment #8) > Hi Rob, > > We cannot extend jst.ear and jst.ejb with newer versions, because internal > checks in WTP code make them behave as old facet versions (see bug 157185). > I think getting resolution to the issues discussed in that bug is the correct course here; the "jst.ear" facet needs to be used so that WTP correctly identifies the project as an EAR project. > Your statement '...your custom facet takes a dependency on "jst.ear" > (effectively "extending" jst.ear)' sounds quite interesting. If we enable both > "jst.ear" (version 1.4) and "jst.new.ear" (version 5) facets in our EAR 5 > module then I suggest that both install delegates of the facets will be > executed. This will cause problems later during runtime. > > Does this "jst.new.ear effectively extending jst.ear facet" differs from the > above? What is the nature of this dependency? Will be the jst.ear install > delegate omitted in this case? Same thing; by "dependency" I mean your "jst.new.ear" facet would include a requires constraint on "jst.ear" (and the "5.0" version of your facet should specifically require the "5.0" version of the "jst.ear" facet). This doesn't get around the issues with the "jst.ear" 5.0 facet that you mention above but it will allow you to have a "official" EAR project with custom facet-based functionality (we've done similar things at BEA for other facets)
Rob, let me clarify the situation with facets in our EAR 5 project. We need to have EAR 5 project in our SAP NetWeaver Developer Studio (NWDS), based on WTP 1.5, that have to be deployed on our SAP NetWeaver Application Server (NWAS). Perfectly such EAR 5 project would have two facets: jst.ear (version 5) and jst.ear.ext (version 5). The latter facet jst.ear.ext is actually an extension of the jst.ear facet that defines the SAP-specific properties for the EAR 5 project: deployment descriptors, natures, etc. that are needed for the EAR 5 project to deploy on the NWAS. Our problem is that we cannot define jst.ear version 5 facet, because of the restrictions in WTP code base already mentioned. This is why we throw away the jst.ear facet and define new one jst.new.ear facet as replacement. For this we also build a whole new set of wizards and UI components to support the functionality of the new facet. In fact jst.new.ear facet imitates the jst.ear facet. However, they are some problems like this one. I hope it is a little bit clearer. Now, the example project with the 2 utilities project is just a demonstration of the problem in a pure WTP environment. The suggested patch is a simple and effective workaround of this situation. And it should not affect the existing functionality in the pure WTP.
hi Kaloyan, thank you for the clarification. I understand your situation now (you would like to use the jst.ear version 5.0 but are trying to build something on WTP 1.5) I agree that the proposed patch is itself very low risk and have no problems eventually seeing it put in, however, I am reluctant at this point to put it up for PMC approval since the release candidate has already benn built and I am concerned that you will hit other problems (necessitating other patches) with this approach: -Using jst.utility projects as EAR projects -Removing the MANIFEST.MF file from the utility project -Representing EAR-to-module dependencies using inter-module dependencies -Representing what WTP will interpret as inter-module dependencies in the component file when those are now maintained in the MANIFEST.MF file Here are some of the problems I think may occur: -Dependent projects of these "EAR" projects will not be seen as EAR dependencies by WTP and will therefore not get the "EAR Libraries" classpath container or have standard J2EE Module Dependencies UI (you may be doing your own UI piece here) -WTP is going to interpret that dependency internally as a module dependency and not as a EAR-to-module dependency - this means that information about the EAR-specific module URIs will not be correctly handled, etc. -I suspect there may be places in the current j2ee classpath container/dependency manager code that could get confused by this structure -other issues that I imagine Chuck, John and Jason can add... I don't know your internal product constraints/schedule but I think your best long term course is to try and find a way to use the jst.ear facet (this not only avoids the potential problems listed about but eliminates a bunch of upgrade work to ensure later compatibility with WTP 2.0). Looks like that would either require building on WTP 2.0 or exploring a way to address some of the issues that prevent you from defining a custom "5.0" jst.ear facet in WTP 1.5 (that would ultimately allow your projects to be compatible with the official jst.ear 5.0 facet in 2.0). It is very possible that additional 1.5 work will be done after 1.5.3 if enough adopters request it (i.e. a 1.5.4). An additional 1.5.x release could be used to explore custom jst.ear 5.0 support or, if infeasible, patches like the one attached to this bugzilla. Chuck/Jason/John: additional thoughts?
Here's another potential problem: -Since your "EAR" in this case is actually a utility project, WTP will display this project as a potential dependency in the J2EE Module Dependencies UI for all jst.ear EAR projects (and as a WEB-INF/lib dependencies in dynamic web projects); users could potentially add this jst.utility "EAR" as a dependency to other projects, with a number of undesirable results (e.g. you will then see the J2EE Module Dependencies UI on your jst.utility "EAR" project and the user could add dependencies to other modules in the jst.ear EAR which would trigger the creation of the MANIFEST.MF file you are deliberately excluding). Other similar scenarios can be envisioned (via both manual and via automatic execution paths). Essentially, if WTP thinks this project is a jst.utility project rather than a jst.ear project, all sorts of actions can occur that can break your use case (and break the WTP code).
Hi Rob, I see there is still some confusion. Forget about the jst.utility facet. We don't have it in our EAR 5 project. Utility projects were used just to demonstrate the problem in pure WTP environment. The only facets that our EAR 5 project has are: - jst.new.ear (replacement of the jst.ear facet) - jst.ear.ext (adds SAP specific properties to the project) By utilizing the extension points in WTP 1.5 we are able to extends WTP in a way that EAR 5 project behaves properly as, well... as an EAR 5 project :) There are just very few operations (like this one) that does not behave properly and we cannot fix it without patching WTP code. Sure, we consider using the original jst.ear facet version 5 that is newly introduced in WTP 2.0 (we are in touch with the WTP developers about this), but we are going to adopt WTP 2.0 in our next release. For the release that we are going to release soon (we are currently in stabilization phase) we stick to WTP 1.5.
Hi Kaloyan, Ah, I see; a number of those potential problems certainly go away in that case. The fact that WTP does not recognize the project as an EAR project will still cause various issues (like this one, handling of the module URI, EAR Libraries cp container, etc.). Q: Assuming there is a 1.5.4, would application of this patch during 1.5.4 (or, ideally, resolution of the issues blocking your creation of a 5.0 version of jst.ear) meet your schedule requirements?
Hi Rob, The release that we are currently validating is the so called CE 1.0. It is based on WTP 1.5.2. The next release - CE 1.1 - is planned to be based on WTP 2.0. However, we may decide to release a service pack - CE 1.0 SP1 - or to stick CE 1.1 again to WTP 1.5. In this case we will use the latest WTP 1.5.x release. In the above context, it make sense for us that this patch is applied to WTP 1.5.3 or eventual WTP 1.5.4 release. If there is 1.5.4, when should we expect it? Also, if the jst.ear version 5 facet in WTP 2.0 does not meet our requirements we will probably not change the architecture of our Java EE 5 support. This means that we will then target this same patch for WTP 2.0.
(In reply to comment #15) > In the above context, it make sense for us that this patch is applied to WTP > 1.5.3 or eventual WTP 1.5.4 release. If there is 1.5.4, when should we expect > it? A decision on a 1.5.4 release has not been formally made yet but looks likely (I believe it would be targetted to release approx. 3 months after the release of 1.5.3) > > Also, if the jst.ear version 5 facet in WTP 2.0 does not meet our requirements > we will probably not change the architecture of our Java EE 5 support. This > means that we will then target this same patch for WTP 2.0. > The change would be made to both the 1.5.x branch as well as 2.0 so you would be covered either way.
Released to 2.0
Verified with the RC4 release.
Verified, closing.
