I browsed through the latest Debian Java Policy
doc, but didn't see anything that looked like it addressed this problem, so I'll
ask...
One of my clients has a web site that's visited by
people with old browsers that don't really handle applets compiled by JDK 1.1 or
higher. For this reaso
I'm having a hell of a time getting jserv 1.1.2-1
to work on Apache 1.3.12-2.1.
I keep getting "Can't find class
org.apache.jserv.JServ". However, the /usr/share/java/ApacheJServ.jar *is*
listed on a wrapper.classpath line in /etc/jserv/jserv.properties.
When I turn on verbose mode, I see
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack on new jar
> file to the classpath every tim
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
> general I would prefer a strictly extension dir
> Ah, wouldn't that be nice. If every package maintained compatibility
> release to release, we could do that. But that doesn't always happen.
> For example, Kawa's package hierarchy is going through some
> reorganization, such that if I compile BRL against Kawa 1.6.67 won't
> work with Kawa 1.6.
> * Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Isn't that what the Debian package "conflicts" and "requires" settings
are
> > for? If I compile Apache against libc5 and then replace libc5 with
libc6,
> > Apache's going to break un
> *And now some stuff about servlet engines
> This gets more complicated when you consider servlet engines. Servlet
> engines should have their code (jars or classes) specified on the
> classpath (ie: 3).
>
> The classes and jar files that define applications (eg: servlets and
> so forth) go in an
> Hi,
>
> does anyone know why JDK/JRE 1.2 and above are not available as
> debian-packages?
They're available, just maybe not from the normal sources. Just go to
www.blackdown.org, then to their download link, then to "debian". You can
get JDK/JRE 1.3.
Another problem might be that you're not se
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
"/usr/share/java/lib" and .class hierarchies in "/usr/shar
> No, it's not that simple: you can always use the completely specified name
> to refer to a class (e.g. "java.util.Vector", even if you don't import the
> package nor the class). The "import" keyword is only there to ease the
> developer's work.
Correct. Many people assume that Java's "import" wo
Joe> Well, to me, "share" means share, which the jvm-specific libs
Joe> aren't meant for.
FYI, traditionally `share' has actually meant
`architecture-independent'.
Fair enough. Since I only go into /usr/share/java and /usr/share/doc, I
had come to view it as the place where architecture-independe
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> > I disagree. My goal is that that /usr/share/java (or
> > /usr/share/java/lib if you prefer) should be similar to Sun's
> > extensions directory: a directory where *all* .jars
> > (i.e. /usr/share/java/*.jar) are added to the impli
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JVM
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
> But I'll spare you that ranting; let's just say I think it's a
horrifically bad
> idea to have a free-for-all in one's classpath. Developer communities
gradually
> gain experience, and if the Java community has learned anything, it's that
> **classpaths are evil**. This is *worse* than a hardcode
> Just being fussy here, don't mind me.
Quite alright. I haven't been keeping close tabs on the development of
Debian's Java policy. Hence, my boo boo
> > 6 - Any .jars in /usr/share/java/respository.
>
> Directory /usr/share/java/repository should only contain class files. The
> jars thems
> Why not just put the jars in /usr/share/java, keep the system classpath
> completely clean, and let the startup scripts for individual apps choose
which
> to include?
Well, keep in mind that the original e-mail that started this thread argued
that Debian was a *developer*-unfriendly system.
Whe
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that the policy is that jars should be installed in
> $JAVA_HOME/jre
> Okay, so have I got this right? The proposal is to have a directory for
> "standard" jars that are auto-included in the classpath for every JVM,
> and a directory for "optional" jars that must be manually specified by
> startup scripts, etc?
Essentially, that's what I'd like to see. However, I
> 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/
Well, I guess what I'm hoping for is to make the learning curve less steep.
I envision being able to download some java so
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've insta
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
> 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.
I'm not really an advocate of the symlinking idea, but am I the only one
that thinks tha
- Original Message -
From: "Michael Gratton" <[EMAIL PROTECTED]>
> Joe Emenaker wrote:
>
> > What if someone releases two jars and foo.jar's manifest makes reference
to
> > "../../../../../../../../bar.jar"? Am I faced with either pu
Mike Gratton wrote:
> Joe Emenaker wrote:
>
> > Granted, my example was entirely contrived, but it was to make a point.
How
> > about a more plausible example:
> >
> > foo.jar makes reference to "../bar.jar". [snip]
>
> I'd still say that&#
> It would be nice to have debconf provide a list of suitable installed
> JVM's. It could also have another option to select the path of a non-deb
> JDK installation.
On a related note
After having just made some .debs for j2sdk1.4, jbuilder6, and jEdit, I had
to write a couple of startup sc
> I was just thinking of a simple way to set up my classpath so I made
> this suggestion. But if it is not common to do somthing like that, then
> I have to live with that. And maybe collecting all libs might not lead
> to the expected result, because of combining libs in different versions
> with
I browsed through the latest Debian Java Policy
doc, but didn't see anything that looked like it addressed this problem, so I'll
ask...
One of my clients has a web site that's visited by
people with old browsers that don't really handle applets compiled by JDK 1.1 or
higher. For this reaso
I'm having a hell of a time getting jserv 1.1.2-1
to work on Apache 1.3.12-2.1.
I keep getting "Can't find class
org.apache.jserv.JServ". However, the /usr/share/java/ApacheJServ.jar *is*
listed on a wrapper.classpath line in /etc/jserv/jserv.properties.
When I turn on verbose mode, I see
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack on new jar
> file to the classpath every ti
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
> general I would prefer a strictly extension di
> Ah, wouldn't that be nice. If every package maintained compatibility
> release to release, we could do that. But that doesn't always happen.
> For example, Kawa's package hierarchy is going through some
> reorganization, such that if I compile BRL against Kawa 1.6.67 won't
> work with Kawa 1.6
> * Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Isn't that what the Debian package "conflicts" and "requires" settings
are
> > for? If I compile Apache against libc5 and then replace libc5 with
libc6,
> > Apache's goi
> *And now some stuff about servlet engines
> This gets more complicated when you consider servlet engines. Servlet
> engines should have their code (jars or classes) specified on the
> classpath (ie: 3).
>
> The classes and jar files that define applications (eg: servlets and
> so forth) go in a
> Hi,
>
> does anyone know why JDK/JRE 1.2 and above are not available as
> debian-packages?
They're available, just maybe not from the normal sources. Just go to
www.blackdown.org, then to their download link, then to "debian". You can
get JDK/JRE 1.3.
Another problem might be that you're not s
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
"/usr/share/java/lib" and .class hierarchies in "/usr/sha
> No, it's not that simple: you can always use the completely specified name
> to refer to a class (e.g. "java.util.Vector", even if you don't import the
> package nor the class). The "import" keyword is only there to ease the
> developer's work.
Correct. Many people assume that Java's "import" w
>
>
> Joe> Well, to me, "share" means share, which the jvm-specific libs
> Joe> aren't meant for.
>
> FYI, traditionally `share' has actually meant
> `architecture-independent'.
Fair enough. Since I only go into /usr/share/java and /usr/share/doc, I
had come to view it as the place where arch
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> > I disagree. My goal is that that /usr/share/java (or
> > /usr/share/java/lib if you prefer) should be similar to Sun's
> > extensions directory: a directory where *all* .jars
> > (i.e. /usr/share/java/*.jar) are added to the impl
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JV
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
--
To UNSUBSCRIBE, email
> But I'll spare you that ranting; let's just say I think it's a
horrifically bad
> idea to have a free-for-all in one's classpath. Developer communities
gradually
> gain experience, and if the Java community has learned anything, it's that
> **classpaths are evil**. This is *worse* than a hardcod
> Just being fussy here, don't mind me.
Quite alright. I haven't been keeping close tabs on the development of
Debian's Java policy. Hence, my boo boo
> > 6 - Any .jars in /usr/share/java/respository.
>
> Directory /usr/share/java/repository should only contain class files. The
> jars them
> Why not just put the jars in /usr/share/java, keep the system classpath
> completely clean, and let the startup scripts for individual apps choose
which
> to include?
Well, keep in mind that the original e-mail that started this thread argued
that Debian was a *developer*-unfriendly system.
Wh
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that the policy is that jars should be installed in
> $JAVA_HOME/jr
> Okay, so have I got this right? The proposal is to have a directory for
> "standard" jars that are auto-included in the classpath for every JVM,
> and a directory for "optional" jars that must be manually specified by
> startup scripts, etc?
Essentially, that's what I'd like to see. However, I
> 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/
Well, I guess what I'm hoping for is to make the learning curve less steep.
I envision being able to download some java so
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've inst
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
> 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.
I'm not really an advocate of the symlinking idea, but am I the only one
that thinks th
- Original Message -
From: "Michael Gratton" <[EMAIL PROTECTED]>
> Joe Emenaker wrote:
>
> > What if someone releases two jars and foo.jar's manifest makes reference
to
> > "../../../../../../../../bar.jar"? Am I faced with either pu
Mike Gratton wrote:
> Joe Emenaker wrote:
>
> > Granted, my example was entirely contrived, but it was to make a point.
How
> > about a more plausible example:
> >
> > foo.jar makes reference to "../bar.jar". [snip]
>
> I'd still say that&#
> It would be nice to have debconf provide a list of suitable installed
> JVM's. It could also have another option to select the path of a non-deb
> JDK installation.
On a related note
After having just made some .debs for j2sdk1.4, jbuilder6, and jEdit, I had
to write a couple of startup s
> I was just thinking of a simple way to set up my classpath so I made
> this suggestion. But if it is not common to do somthing like that, then
> I have to live with that. And maybe collecting all libs might not lead
> to the expected result, because of combining libs in different versions
> wit
54 matches
Mail list logo
