Joe, On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote: > > > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote: > > My solution to the above problem is at: > > > > http://newgate.socialchange.net.au/~jeff/jpe/
[snip] > The lynchpin to what I'm proposing is that narrower-scope things are allowed > to pre-empt wider-scope things. Great, that would mostly solve my problem. My immediate concern is that there's currently no way to override a classpath set in /usr/bin/java. I think that currently, everyone (even deviant thinkers like Per;) agrees that an override is necessary. > [snip examples of user-stuff overriding system stuff] > > > Adding directories to classpath > > Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/classes > > Loading jars from /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib > > Adding > /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/commons-beanutils.jar > > Adding > /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/commons-collections.jar > > Adding > /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/commons-digester.jar > > Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/struts.jar > > Adding /home/jeff/tc/webapps/struts-tiles/WEB-INF/lib/tiles.jar > > Yup. Autodiscovery. I've written a script a few times that does the same > thing. I'll bet *thousands* of other people have, too. That's the problem; > thousands of people writing almost the identical script... differing only in > the names of the directories (you use > "/home/jeff/tc/webapps/struts-tiles/WEB-INF/lib" and I use > "/home/jemenake/projects/java/lib"). Well.. the the point of my script is that, whichever directory you're in, it will add the jars from that project's lib/. I didn't customize a thing for the example above. So if you're in /home/jemenake/projects/java/, and type "proj.sh" (proj.sh must be in your PATH), then lib/* will be added to your classpath, along with any other dirs which your /etc/projrc considers "default". If your projects are self-contained (lib contains all required jars), then this "proj.sh" mechanism is all that's required. The convenience of a system classpath becomes unnecessary, because you can instantly get a project-specific classpath at any time. > Part of what I'm suggesting is that *one* person write this script > *one* more time and that they write it so that all you and I have to > change is some env variable or something to tell the script where our > "personal" jars are. Then, build the script into whatever invokes the > JVM. As long as it's not purely additive. I want to be able to remove stuff from the classpath, not just add my stuff. There are various subtle problems that can occur otherwise: - Say lib-foo-java version 2.0 completely removes a class that previously existed in version 1.0. If I have 1.0 in my system classpath, then even if I override it with 2.0, the extra class from 1.0 is still in my classpath. This will cause sealing violations if the jar is sealed (think jaxp.jar). - Say my system classpath contains xerces 1.4.0. I require a bugfix in xerces 1.4.1, so I should put that in my project classpath. But say I screw up the syntax, or my 1.4.1 jar is corrupt, or I simply forget; my app will superficially work with 1.4.0 and I'll be none the wiser until it dies unexpectedly. I then spend all weekend tracking down what *looks* like a bug, but is really an environmental issue. Sure it sounds stupid, but I've done it before, and I'd much prefer for things to die properly. Problems like these may only bite 1 user in 100, but they effectively mean: - I cannot develop apps without unknowingly relying on a system jar. - I cannot deploy apps to a Debian box, and be completely confident that the system classpath won't cause obscure problems due to classpath conflicts. Whether the advantage in terms of ease of use outweighs this, it up to you. But as I hope my script demonstrates, having a system classpath is not the *only* way to avoid mucking with classpaths. --Jeff > - Joe
