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