Community
Participate
Working Groups
Three problems: 1. Jars copied directly into the EAR's root folder should automatically be added as archive libraries to the EAR's .component file. 2. The Module property pages need to read the .component files (instead of the MANIFEST.MF) to determine their manifest references. 3. Changes to the MANIFEST.MF need to automatically update the .component files and vice-versa
Please increase the severity since this is a major problem. We also have to be careful about adding loose archives in the .component file. I think it would be best to dynamically calculate the loose archives and not worry about the .component file.
Created attachment 43369 [details] A patch file This patch is a first attempt. There are probably a few additional bugs which I intend to fix as I find them, but I wanted to get this patch in the defect as quickly as possible to give other people a chance to try.
Created attachment 43399 [details] A better patch This patch should be used instead of the one above. It prevents duplicate entries from being added to the classpath (essentially fixing 142328)
Does the original bug description still accurately describe the behavior changes implemented by the patch? I am a bit worried that this is a rather extensive change to be doing this late in the release and I am trying to figure out if it will have adverse affects on BEA usecases. More details would be very helpful.
Created attachment 43500 [details] Contains 142328 This patch also contains the fix for bug 142328 which overlaps with this fix.
Kosta, Yes the original description still applies. The main changes I made were to create two subclasses of VirtualComponent; one for the EARs and one for Modules. These two classes were created to help with the syncrhonization issue of keeping the .component files up to date with respect to .jar files in the EAR projects and with MANIFEST.MF dependencies in the module projects. Basiscally the EARVirtualComponent will return additional component references to dyamnically created components for each .jar file mapping to the root folder. Along the same lines, all module components will return dynamically create references for all entries in the MANIFEST.MF file. This way, each module component does not need to track duplicate information in both the MANIFEST.MF and .component files to determining its dependencies. Now the MANIFEST.MF file is the end all authority for references and classpath info (which is good because this is how it will be at runtime). Along the same lines, it is no longer necessary to make an entry in the EAR's .compoennt file for loose jars. So, now, a user can put any .jar file under the EAR's root folder (default EARContent) and immediately start using it. There is no synchronization requirement on the tooling to add a .component entry for loose jars of this sort. These two subclasses are automatically returned from ComponentCore.createComponent() based on extension points & facets, so from a tooling stand point this is totally transparent because ComponentCore.createComponent() is the only place (other than some tests) where VirtualComponents were ever instantiated. Both these new components are smart enough to only new up dynamic references and components when necessary; i.e. if there is already an entry in the .component file it will use that instead. The remainder of the changes are simply listening mechanisms for picking up changes to the EAR's root folder and modules MANIFEST.MF files. Other changes were to no longer the now unnecessary hard references in the .component files. Futher changes were made to the classpath container to not add duplicate entries for projects/jars already existing on the classpath (i.e. from previously created projects).
Making a note for the record. Had a chat with Jason on the phone. It sounds like there shouldn't be any semantic changes to the virtual component api as the result of this. The code that manually creates references will continue to work as before. The calls might no longer be necessary, but it should no-op gracefully.
Created attachment 43542 [details] Also contains 144552 This patch includes everything from above plus a the fix for bug 144552 which I will dupe againse this bug.
*** Bug 144552 has been marked as a duplicate of this bug. ***
*** Bug 142328 has been marked as a duplicate of this bug. ***
+1 This sure looks like some big code changes, so, glad its had such careful review. Tip for future: you should obsolete patches when you replace them with better ones.
+1 1.5
code dropped to head.
closing.
