geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: war manifest classpath in ear (GERONIMO-2125)
Date Tue, 11 Jul 2006 15:30:27 GMT

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


Mime
View raw message