Re: Is there a solution to my problem? (Re: Symlinking jars is dangerous (Re: The evils of /usr/share/java/repository))
On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> > Ben Burton <bburton@mail.math.okstate.edu> writes:
> > > /usr/share/java/foo-version.jar
> > > /usr/share/java/foo.jar -> foo-version.jar
> >
> > Tread carefully. This could have unpredictable results.
> >
> > The extension directory $JAVA_HOME/jre/lib/ext currently points to
> > /usr/share/java, so /usr/share/java is serving as the extension
> > directory.
This is a j2sdk issue and it should be quite easy to solve.
> > The extension class loader is very aggressive and looks at all
> > classes and jars in $JAVA_HOME/jre/lib/ext *and*
> > $JAVA_HOME/jre/lib/ext/* (which is probably what caused this
> > repository issue in the first place). This is my impression of how
> > it works after pouring over the sun.misc.Launcher$ExtClassLoader
> > source.
> >
> > Thus, it would be a bad idea to put all versions of a jar in the
> > extensions directory.
> >
> > Instead I'd put the versioned jar files in /lib/package (with all
> > the other C versioned libraries--I don't see any reason to segregate
> > them, except as noted above) and link to the desired version from
> > the extension directory.
> >
> > Alternatively, we could put all the versions in /usr/share/java, and then
> > make $JAVA_HOME/jre/lib/ext a directory containing jars linked to
> > the desired version of the jar in /usr/share/java.
>
> My turn to say "tread carefully".
>
> Symlinking jars can be dangerous, because jars can contain a Class-path:
> line in their manifests. These Class-path: lines contain relative
> references to other jars. This causes two problems:
What does this reference mean? Is it the same as adding that jar to
the classpath?
Does it exist only in java2?
If this is the case we have the solution on the dependency problem!!!
We should just have a policy on how to name them. :)
> - If the packager has gone and renamed the jar, then Class-path:
> references in other jars will break.
>
> - The Class-path: reference is relative (may contain ".."). Say you
> have /usr/share/java/jaxp.jar, and symlink it to your VM's lib/ext
> directory. Those relative Class-path: references are going to be
> relative to /usr/share/java, *not* your VM directory. So even if you
> symlink one jar to lib/ext, that jar may haul in a bunch of other
> jars.
The policy should say that every Class-path: must be relative to the
/usr/share/java dir. Which means that they should (almost all time)
just be the jar filename.
> Here's someone who just got burnt by symlinking jdom.jar:
And they should of course just point to packaged jars.
> http://www.servlets.com/archive/servlet/ReadMsg?msgId=143649&listName=jdom-interest
>
> "I've just spent several days tracking a nasty CLASSPATH problem
> created by an entry in the Beta 7 MANIFEST.MF entry.
> ..
> What makes this so evil is that the JVM's under Linux resolve symbolic
> links. When an symbolic link to jdom.jar is placed in some project's
> lib directory, both Linux JVM's still load the ../lib/xerces.jar
> RELATIVE to the REAL jdom.jar file."
So we should really say something about this in the policy. :)
> > I don't think we should mess with CLASSPATH in the scripts. This is
> > a user-configurable variable.
> >
> > I don't think /etc/alternatives is a solution here. We should do
> > something similar to the C shared library versioning.
> >
> > In general, I think we want to continue using the extension
> > directory to inject jars into java and javac.
>
> Another point about lib/ext. The JVM treats all jars in lib/ext as
> priveleged, like java.lang.*.
>
> "By default, installed extensions are granted all security permissions
> as if they were part of the core platform API"
>
> -- http://java.sun.com/docs/books/tutorial/ext/security/policy.html
>
>
> IOW, symlinking a bunch of jars to lib/ext is not the same as including
> them in the regular classpath.
>
> Now, do we really want to preclude the use of a SecurityManager in any
> Debian-packaged Java app?
Probably not. So the lib/ext dir should be empty, right?
> Really, there are so many complicated issues when you start trying to be
> clever with classpaths. I don't know half of them.
>
> I'm concerned that if Debian's java policy tries to do anything out of
> the ordinary, it will cause *someone* out there grief. It will then be
> very hard to rectify the situation. Look at the current situation with
> /usr/share/java/repository. So IMHO, the only safe thing to do is keep a
> clean classpath, put jars in /usr/share/java, and let startup scripts
> choose them. If you miss the ease-of-use of a system classpath, set it
> in your .bash_profile, or use something like
> http://newgate.socialchange.net.au/~jeff/jpe/
Or have two different alternatives. One with a "easy classpath" and
one with a "clean classpath". I think I like having two alternatives.
But how do we do that in practice? Two wrappers or anything else?
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: