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
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 wor
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
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 d
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 o
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 funct
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 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 no
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
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
> 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 classloade
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
> 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 possibl
Christopher Cain wrote:
>
> 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.
^
Oops. There should be a "4.0" there =)
- Christopher
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
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, I
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 t
17 matches
Mail list logo
