geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ruebsam <>
Subject Re: war manifest classpath in ear (GERONIMO-2125)
Date Tue, 11 Jul 2006 17:20:27 GMT
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:

Also the class path entry is relative to the war file not the WEB-INF/classes
or WEB-INF/lib in the war file.


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/
> -dain

View raw message