Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=sDOO5ZIkQcpU+ciY2jSK3HqqXRS3ZwEiLT57YynEFHFfdq4X/cxwUk5+xXv27QpmKyFZTCam36Lf2nMVkAozqE5I2mXQrq7vXx9uyNYC2y3d+RlRUZxDFzBfRLhAdD1eoo0ZnPufx3uR2IzeKEWOWnu2H/a8J5janv+dbZRIs0Y=
Message-ID: <74e15baa0607110845h3ba80febodb24b1e0cc193940@mail.gmail.com>
Date: Tue, 11 Jul 2006 11:45:14 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: war manifest classpath in ear (GERONIMO-2125)
In-Reply-To: <CAB938A5-5920-44F8-98EA-75ABE4E602B7@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <D64BA4F5-A978-41DE-8965-646F91628BF3@yahoo.com>
	 <74e15baa0607110803w793c34dape753f3e2b289d41c@mail.gmail.com>
	 <CAB938A5-5920-44F8-98EA-75ABE4E602B7@yahoo.com>

I'm not sure what you mean by "keep track of the stuff inside the war
and inside the ear
separately" -- I don't think I understand the issue.  But the option 4
that you like (everything relative to EAR location) sounds fine to me
too.

Though, I guess I need to ask -- if you have a relative manifest
Class-Path entry in a WAR in a subdirectory of an EAR, is it relative
to the WAR location within the EAR or the EAR root?  I guess I had
been assuming it was relative to the EAR root, but now that I think
about it, it would make more sense to be relative to the WAR location
within the EAR, so ".." would be fine.  Anyway, I still like option 4.

Thanks,
    Aaron

On 7/11/06, David Jencks <david_jencks@yahoo.com> 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.
>
> >
> > 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.
>
> Any further thoughts?
>
> thanks
> david jencks
>
> >
> > Thanks,
> >    Aaron
> >
> > On 7/10/06, David Jencks <david_jencks@yahoo.com> wrote:
> >> I've finally managed to reproduce the problem in GERONIMO-2125, in
> >> which you have an ear, with a war inside, with a manifest classpath,
> >> and the stuff on the mcp doesn't work.
> >>
> >> The problem is pretty much caused by our new configuration for the
> >> war, although I think a similar problem would occur for an exploded
> >> ejb jar in an ear. ( I suspect the latter doesn't work at all now,
> >> since in that case we should manually add the mcp entries to the cp,
> >> which we don't)
> >>
> >> so, we a uri out of the mcp, and try to resolve it against the war
> >> config base uri, such as web.war, and add it to the config classpath,
> >> so we get e.g. an entry of jar.jar.  However, this is relative to the
> >> war config, which does not have this jar in it: it's actually in the
> >> containing ear config, typically up one directory.
> >>
> >>
> >> e.g.
> >> ear config is at
> >> /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-
> >> server/
> >> target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/
> >> 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car
> >>
> >> war config inside it is at
> >> /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-
> >> server/
> >> target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/
> >> 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car/web.war
> >>
> >> the mcp entry should be
> >> ../jar.jar
> >>
> >> or we need to copy another copy of the jar.jar into the war
> >> configuration.
> >>
> >> I'm in favor of relativizing the mcp entry to ../jar.jar but I'm a
> >> little worried about the consequences.  Anyone see any problems with
> >> this?
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >>
>
>