Just clarifying, you basically want the exact same functionality
you'd get by copying the jars into the individual webapp lib
directories, but you just don't want to have to copy them. Right?
-Paul Speed
Rick Mann wrote:
on 8/30/01 4:22 AM, Glenn Nielsen at [EMAIL PROTECTED] wrote:
on 8/30/01 11:36 PM, Paul Speed at [EMAIL PROTECTED] wrote:
Just clarifying, you basically want the exact same functionality
you'd get by copying the jars into the individual webapp lib
directories, but you just don't want to have to copy them. Right?
Look, if it were the exact same
I wasn't trying to be rude. I was just summing up a fairly large
discussion that touched on everything from classloader sharing to
security to where any changes would reside.
You want several web apps to have access to the same jar file as
if each had their own private version, ie: no sharing
This entire thread has grown tiresome, my own posts included =)
Look, if you want shared classes for multiple webapps, but not all
webapps, then:
1) Create a common directory outside of TC
2) Put the jars there
3) Create symlinks to the jars in the relevant WEB-INF/lib subdiretories
It can be
First off, I apologize for being rude. It wasn't my intent. But I was trying
to quash what I interpreted to be a deliberate attempt to say just do
this. The point I'm trying to make is that this (the solutions proposed
so far) don't really solve my problem.
So, please accept my apologies for
Rick Mann wrote:
First off, I apologize for being rude. It wasn't my intent. But I was trying
to quash what I interpreted to be a deliberate attempt to say just do
this. The point I'm trying to make is that this (the solutions proposed
so far) don't really solve my problem.
No worries :)
On Wed, 29 Aug 2001, Rob S. wrote:
Date: Wed, 29 Aug 2001 16:39:38 -0700
From: Rob S. [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Extending Server.xml configurability
(foradditionalclasspaths)
No worries; in fact, I really don't understand
on 8/30/01 4:22 AM, Glenn Nielsen at [EMAIL PROTECTED] wrote:
Why won't installing the jar files in $CATALINA_HOME/lib and making them
available to all web applications meet your requirements?
Is there a security reason why some web applications can use the classes and
others should not?
on 8/29/01 2:00 PM, Christopher Cain at [EMAIL PROTECTED] wrote:
better than the above. It's an infinitely cleaner approach. You must be
a Windoze guy to hate symlinks that much ;-)
Actually, I'm a Mac guy. But I'm running Tomcat on Mac OS X, which is
essentially BSD. I just find the links to
on 8/29/01 3:23 PM, Rob S. at [EMAIL PROTECTED] wrote:
When I wrote the email, I wasn't implying that whatsoever, but I can see
quite clearly now how it could be taken. Apologies for that implication...
No worries; in fact, I really don't understand the mechanism. However, if it
helps me,
Rick Mann wrote:
[snip]
Now, to avoid changing the spec, which I understand to be the Servlet 2.2
spec
Depends on which version you're using. Tomcat 3.x conforms to the 2.2
spec. Tomcat conforms to the almost-finalized 2.3 spec.
which also understand to specify the structure of the
No worries; in fact, I really don't understand the mechanism.
However, if it
helps me, I'd like to understand it. Since then, I've read about the
ClassLoader, SecurityManager, and System classes.
I'm still getting used to be back in Vancouver, so I dunno if Craig has
mentioned, or possible
on 8/29/01 4:39 PM, Rob S. at [EMAIL PROTECTED] wrote:
You're talking about a source-level modification, right? In the
org.apache.catalina.startup.Catalina (i *think*) there's the initial
creation of the non web-app classloaders. A good place to start looking at
per-app class loaders is
Actually, I want to do this within my webapp. I was thinking of
providing an
init-param to a class that gets loaded on startup, that then installs its
own classloader based on that init-param (which would be a path
or series of
paths to search for classes).
Writing your OWN classloader?
on 8/29/01 5:11 PM, Rob S. at [EMAIL PROTECTED] wrote:
Writing your OWN classloader? Ugh... you're going to kill portability,
Well, no. I meant write my own classloader that is part of my web app. That
should be doable, right? I can't tell from the poor little Java book I have,
if a Java app
Rick, this is really what I was trying to say. Chris puts it so well I may
as well stop replying ;)
- r
True, server.xml is Tomcat-specific, fluid, and can be changed, for the
most part, at will. The reason you will have trouble convincing many of
the core developers to change server.xml is
16 matches
Mail list logo
