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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> >> >>
