Community
Participate
Working Groups
Build Identifier: WTP 3.2.1 There are some issues removing previous entries from the application.xml file when the deploy path is changed using the 'Deployment Assembly' page. Also, the URI for new module added using the 'Deployment Assembly' page are generated with a '/' at the beginning when it is not necessary since it is based on the root by default. Steps to recreate: 1) Create an EAR 5.0 with all modules and with a DD 2) Modify the deploy path of any of the module entries. 3) Open the application.xml (A new entry has been added with the changed deploy path but the previous entry was not deleted). 4) Create a new EJB project and don't add it to the EAR. 5) Go to the Deployment Assembly page of the EAR and add a reference to the new EJB project. (This adds an entry to the application.xml file with the URI of '/NewEJBProject' instead of the expected 'NewEJBProject.jar' (without the '/' in the front)) Reproducible: Always
Created attachment 174925 [details] Proposed Patch This patch updates the AddComponentToEnterpriseApplicationOp.updateEARDD() method so that when calculating the URI that is to be used when the module is added, if the runtime path is the root ('/') then if should add it as a prefix to the archive name. The RemoveComponentFromEnterpriseApplicationOperation.updateEARDD() method is also modified so that modules are removed based on their dependent-object ids instead of on their URIs.
I just wanted it known that I approve of this change, and that this is important for WTP- we have let inconsistency in the way that the URI is handled in regards to the leading slash in the URI creep into WTP 3.2.0. This addresses that important issue.
approved
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This bugzilla addresses 2 important issues for WTP: 1) When the deploy path is modified using the 'Deployment Assembly' page, there are some issues removing previous entries from the application.xml file (A new entry is added with the changed deploy path but the previous entry is not deleted). 2) The URI for new modules added using the 'Deployment Assembly' page are generated in the application.xml file with a '/' at the beginning when it is not necessary since it is based on the root by default. * Is there a work-around? If so, why do you believe the work-around is insufficient? No. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested through UI. * Give a brief technical overview. Who has reviewed this fix? The issues mentioned in the problem description are fixed as follows: 1) The RemoveComponentFromEnterpriseApplicationOperation.updateEARDD() method is modified so that modules are removed based on their dependent-object ids instead of on their URIs. 2) The AddComponentToEnterpriseApplicationOp.updateEARDD() method has been updated so that when calculating the URI that is to be used when the module is added, if the runtime path is the root ('/') then it shouldn't add it as a prefix to the archive name. Chuck Bridgham and Carl Anderson reviewed this patch. * What is the risk associated with this fix? Low.
As discussed in status meeting, I agree with a respin to pick up this fix, even though would not be noticed at first by casual users (or testers). The reason that convinced me is that the longer someone works with this "broken" version, the more messed up their metadata gets (having more dual entries) so even if we fix the issue in a later maintenance release, by then, users would have a lot of "manual" cleanup to do (at best).
Created attachment 175031 [details] Proposed Patch Updated Patch was updated to handle the case where the module's dependent object is not set or is incorrect and the case where the StructureEdit of the component that is to be removed is not present (project was renamed). In these cases, the RemoveComponentFromEnterpriseApplicationOperation.updateEARDD() will remove the module entry from the application.xml file based on the archive name.
For the record, I ran the entire Java EE Tools JUnit bucket against these patches. The "Proposed Patch Updated" patch runs successfully. (The initial patch had a problem which the JUnit bucket uncovered.)
Committed to HEAD for WTP 3.3. (And tentatively WTP 3.2.1, assuming PMC approval)
