This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
ArchiveMemberSet.removeEntry() is failing to remove the requested entry. The ArchiveController implementation used by several of the EE modules, in processMemberSet(), calls ArchiveMemberSet.removeEntry() to remove a data object from the jar contents. This is not working and the files associated with the data object are being packaged in the jar. For example, if you use the Export EJB Jar action on an EJBModule and then examine the resulting jar, you will see a number of files which have the name of the EJBModule and various extensions. These are the EJBModuleDataObject's files. We remove the EJBModuleDataObject from the jar contents using removeEntry(), so these should not appear. This was working until recently. It looks like a regression from the fix for 20712/20387. In that fix, the HashMap of entries was changed to use a ContentMember as the key instead of the DataObject. However, in various places the code still does a look up with a DataObject as the key. In removeEntry() it is looking for the entry to remove using the DataObject as the key, but the entry was added with a ContentMember as the key so the entry is not found and is not removed. I experimented with changing removeEntry() to take the ContentMember (actually ArchiveMember) as the parameter. However, in processMemberSet() what we have is the ContentMember which is the hash map value, and this is not the same object as the ContentMember which is the hash map key, so the lookup still fails.
I am not able reproduce this behaviour (Build 200203080100).
There is list of files in .jar (Orion EA): EJB_Module.ejbjar-contents EJB_Module.ejbjar-lce EJB_Module.ejbmiascmp EJB_Module.ejbmodj2eeri EJB_Module.ejbmodule EJB_Module.ejbmodule-dd EJB_Module.ejbmoduleias EJB_Module.ejbmodweblogic
Yes, those are the files which are *not* supposed to be in the jar.
Not a P1 no loss of data. P2 at best.
Roger, I see you have changed this bug from P1 to P2. This worries me as this is a critical bug for FJEE in orion. Please confirm that this will be fixed for orion (netbeans 3.3.2). Thanks -Andrew
This bug causes significant performance issues when deploying a j2ee application because a very large file gets (erroneously) included in the ear.
What is the ArchiveMemberSet class that you are using. Is it your own or one suppied by JarPackager?
Do you mean removeEntry or removeMember?
Sorry about that, it is removeMember. We are using the ArchiveMemberSet passed to us by the jarpackager.
I think this is a one line fix. Line 518 of ContentMemberList.java needs to be changed from if (entries.remove(child.dataobject) != null) { to if (entries.remove(child) != null) { The problem was the addEntry was adding the child while the remove was trying to remove the child.dataobject. I've asked Dana to test this change since I don't have the right environment and I'm not likely to have it before I go on vacation in 2 hours.
Problem fixed. Reviewed by Dana Bergan. Will submit INF for inclusion in Orion-ea
I did review the fix but I said that it was not correct and would not fix the problem.
This bug has been fixed as described below in orion_fcs branch. I will integrate the fix to the netbeans trunk shortly and will close this bug then. The problem was introduced by the fix for iz 20712/20387. In that fix the key to a hash map of jar entries was changed from a DataObject to a ContentMember. However, the new key was used for adding entries to the hash map, but other code that looks up entries in the hash map was not modified to use the new key. Consequently, when the j2ee assembly modules called removeMember(DataObject), the DataObject was not found in the hash map because the wrong key was used for the lookup. So, nothing was removed and the extra files ended up in the jar. The fix is to back out these changes to ContentMemberList and some of the changes to JarContentChildren since these changes were not actually necessary to fix 20712/20387. The changes to JarContentChildren which were necessary to fix 20712/20387 have been left in place. Prior to the 20712/20387 fix, JarContentChildren used the DataObject as the key for the child nodes. Since the tag lib editor module associates more than one ContentMember with one DataObject, this resulted in 2 duplicate nodes instead of 2 distinct nodes. Now, JarContentChildren uses the ContentMember as the key for the child nodes and the tag library members display correctly. However, there is an inherent problem in the way the tag library editor is using the jarpackager which may lead to other bugs. The JarContent object is designed with the assumption that there is a 1-to-1 correspondence between a DataObject and a ContentMember. The API prevents you from adding more than one ContentMember for a given DataObject. The tag library editor gets around this by cloning its DataObject and adding the second member using the cloned DataObject. This seems to work for the current IDE session, but when you shut down and restart, the deserialization of the JarContent restores its DataObjects using the primary file for the DataObject as its identifier. After deserialization, what was a cloned DataObject becomes the original DataObject and there are now 2 entries with the same DataObject. This violated the assumption of the JarContentChildren that there would not be 2 entries with the same DataObject. The fix for 20712/20387 eliminates that particular problem, but there are other places in the jarpackager code where that assumption is made. This is really not a jarpackager bug at all since the API enforces this constraint and provides an alternative mechanism. The right way to add 2 files from one DataObject is to use an ArchiveController.
Backing out the changes made for 20712/20387 would result in the tag library editor generating jars that do not contain META-INF/taglib.tld, which would mean they cannot be used with the jar-based uri specification. This would be a P1 bug for the tag library editor. Adding an archive controller at this point would be way too risky for orion fcs. I submit that the JarContent API's assumption of a 1-1 mapping between data objects and content members is not correct, and goes against the requirements we submitted to the jar packager team in the post-pilsen time frame. Another possible solution is to implement a version of removeMember(DataObject) that iterates through the hashmap checking against the data objects directly, even if the entry is hashed according to a content member. This would be an order(N) algorithm on the hash map's members. However, I'm under the impression that the jars aren't really going to be large enough for that to be a serious consideration.
As noted above, I did not back out the entire fix. I believe tag library editor should see correct behavior now. If it does not, please describe the incorrect behavior seen in a build containing my changes. Based on my experiments with and without Roger's changes, prior to his fix there was no problem with the actual jar, only with the UI display of the jar entries. I agree that it wouldn't be appropriate to implement an archive controller in the Orion timeframe. That's why I left the fix in place which addresses the symptoms. I just wanted to raise the issue that the current situation is fragile and likely to break somewhere else. I'm not the jarpackager owner so I'm not going get any further into a discussion of how the jarpackager should be changed in the future.
Created attachment 5232 [details] Diffs of fix
Fix checked into trunk. Diffs attached.
An updated fix has been added that correctly fixes 21332, 20712 and 20387. QA needs to test fixes in trunk before they are incorporated into other branches
Verified
Resolved for 3.4 or earlier, no new info since then -> closing.