Lots of threads on this issue today. I'm not sure I know all the
scenarios, but I will comment since it was asked for ;)
I'd appreciate the appearence of the "class-path" in the manifest obeyed
from the deploy dir. So if you copy it, you can have relative (ie: no
leading slash) or absolute references. If they are relative, they may not
be a jar, but a whole directory. It would be difficult to copy them. So
perhaps fixing the "Class-Path:" by prepending "/path/to/deploy/dir/" to
the entries. Unix allows "/deploy/dir/../../classes" to
resolve. hopefully the classloader wouldn't have a problem with this.
But yes, any solution (even a hack) would be appreciated. If it's
recommended only for use in development cause it's too hackish (which it
would be used more frequently perhaps?), that would be accetable.
Thanks,
Kenneth Topp
On Wed, 16 Aug 2000, Rickard [iso-8859-1] �berg wrote:
> Hi!
>
> (CC'ed to jboss-dev)
>
> [EMAIL PROTECTED] wrote:
> > Sorry, its just mistake in letter - in manifest.mf really-> Class-Path: util.jar
>idgenerator.jar (with ":")
>
> Ah, ok.
>
> Hm.. wwwait a minute.. I know what it is :-( We copy jars on deploy so
> that we can undeploy and redeploy without getting file access problems.
> The copy in the tmp dir is not in the same place as the original jars,
> so the references break.
>
> Damn. Knew this would come some day. So, if we don't copy the references
> work, and if we copy the references break.
>
> Either:
> 1) Don't copy and try to do read-only ClassLoading from it
> 2) Copy, but check the jar and add the Class-Path manifest header
> references to the EJB classloader
>
> 2) is fairly simple and would work. However, if we could get around the
> need to copy to tmp that would be better.
>
> Comments?
>
> /Rickard
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
