On 7/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
You're right. Here are some snippits from the j2ee 1.4 spec: ...
Wow, I had thought that was all optional. Guess not!
Given the above text the I would categorize this bug as a blocker for 1.1.1.
I agree. Thanks, Aaron
On Jul 11, 2006, at 10:20 AM, Mario Ruebsam wrote: > I'm not sure but I think the Class-Path entry in war files is covered > by the spec because EAR, WAR and RAR are JAR files. J2EE 1.4 > excluded EAR files from that. EAR manifest files should not contain a > Class-Path entry. > > packaging description from sun: > http://java.sun.com/j2ee/verified/packaging.html > > Also the class path entry is relative to the war file not the WEB- > INF/classes > or WEB-INF/lib in the war file. > > Thanks, > Mario > > > Dain Sundstrom wrote: >> On Jul 11, 2006, at 8:30 AM, David Jencks wrote: >>> On Jul 11, 2006, at 8:03 AM, Aaron Mulder wrote: >>> >>>> What if the WAR is in a subdir within the EAR like foo/bar/ >>>> some.war? >>>> Then ".." alone won't work to resolve paths relative to the EAR. >>> >>> Yes, whatever relative path we might generate certainly would >>> have to take account of the position of the war inside the ear. >> IIRC, the manifest class path is relative to the archive itself. >> In this case it is relative to the some.war, so if you want >> something in the foo dir, the manifest class path entry would have >> to be ../../jar.jar >> Also, I think all of this is out side of the spec. IIRC the spec >> only talks about manifest class path entries of jar files, and >> since a war is not a jar file it isn't covered by the spec. >> Regardless, I think it is a good idea to support this, but I want >> to clarify that I don't believe this is a certification issue. >>>> I would think from a WAR-in-EAR, we could identify the Module ID of >>>> the EAR, and then use the repo to construct a path to the JAR-in- >>>> EAR >>>> with the EAR module ID and the JAR path. Is there a reason why >>>> that >>>> wouldn't work? >>> >>> IIUC you are suggesting that the war configuration/module keep >>> track of two parts of its classpath: one inside itself, for WEB- >>> INF/lib and WEB-INF/classes, and one inside the enclosing ear, >>> for the manifest classpath. This certainly seems possible to me >>> but I wonder what advantage it would have over only tracking >>> stuff in one place. >>> >>> So, now I see even more possibilities: >>> >>> 1. copy the manifest cp entries from the ear into the war. This >>> would keep the war self contained, but otherwise seems like a lot >>> of extra work for nothing. >>> >>> 2. keep track of the stuff inside the war and inside the ear >>> separately (your proposal IIUC) >>> >>> 3. keep track of the war classpath based on the war location >>> inside the ear, so manifest classpath entries get a ../ prepended >>> to them (if the war was in a subdirectory in the ear, manifest cp >>> entries would most likely already have one or more ../ since >>> entries are relative to the war location). >>> >>> 4. keep track of the entire war classpath based on the ear >>> location, so the stuff in WEB-INF/[lib,classes] would have the >>> war location inside the ear prepended. >>> >>> I'm tempted by (4). To me it says, here's the ear with a lot >>> of stuff inside, and you can define classloaders that access an >>> arbitrary subset of the stuff inside. I think this is the most >>> compatible with the idea that's been floating around for a while >>> of keeping the configuration separate from the j2ee artifact that >>> is is based on: i.e. copy (possibly with unpacking) the j2ee >>> artifact into the repo, and not into the car file: the car file >>> just gets pointers into the j2ee artifact to define its classloader. >> Um I didn't really understand all the options, but I would like to >> suggest that the class path contain patterns (the code is already >> in place for this) and we resolve these patterns against the root >> dir of the war. For manifest class path entries, we would just >> need to prepend each entry with ../ to get outside the war dir >> and prepend them to the class path with the manifest entries. For >> example, the example aaron used above would result in the following: >> War base dir: foo/bar/web.war/ >> War class path: ../../../jar.jar lib/classes lib/*.jar lib/*.zip >> Final class path: foo/jar.jar >> foo/bar/web.war/lib/classes >> foo/bar/web.war/lib/lib.jar >> foo/bar/web.war/lib/lib.zip >> -dain