geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: war manifest classpath in ear (GERONIMO-2125)
Date Tue, 11 Jul 2006 18:06:59 GMT
On 7/11/06, Dain Sundstrom <dain@iq80.com> 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
>
>

Mime
View raw message