You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Cain <cc...@mhsoftware.com> on 2001/08/29 22:15:16 UTC
Re: Extending Server.xml configurability (for additionalclasspaths)
Rick Mann wrote:
>
> on 8/28/01 9:08 PM, Rob S. at rslifka@home.com wrote:
>
> >>> I've seen lots of discussion on the user list desiring the
> >> ability to have
> >>> additional classpaths available to web applications, but not necessarily
> >>> available to all web apps.
> >
> > ...mainly because people don't take the time to understand the class loading
> > mechanism, and ask for things they wouldn't otherwise, if they knew what was
> > going on =) This happens a lot of times when people are learning new
> > technology.
>
> So, it seems that you're saying that I don't understand the class loading
> mechanism. Aside from the discussion about why that doesn't obviate the need
> for a way to extend the class path in the configuration files (be it
> Server.xml, web.xml, or in the war manifest), can you tell me if there is a
> solution here?
>
> I would like to be able to have a webapp find necessary classes in an
> arbitrary directory, specified as a property. If you can tell me what class
> I can invoke to perform this, then perhaps that would be enough. However, I
> still feel that the original request is valid.
I'll throw an idea out here, although it may well get shot down for
either spec non-compliance, possible security concerns, or just general
lack of sex appeal ;-)
I wouldn't mind providing a way for certain webapps to share classloader
a repository, primarily from a deployment point-of-view. It would be
nice to only have to deploy a new jar or class in one place rather than
several. Like most others who have responded, I am pretty -1 on having
Tomcat once again use the system classpath. That was way more trouble
than it was worth. I am also pretty hesitant to respect any paths
specified in a manifest, since that opens up something of a security can
of worms IMHO.
So how about this. What are the thoughts on removing the ".jar" check on
the WEB-INF/lib classloader, and making a few minor tweaks to allow
subdirectories to be loaded in addition to jars? That way, a subdir
could be a soft link to centralized directory if the wants to set it up
that way. From a security standpoint, I don't necessarily see it as
being any more troublesome than loading whatever jars happed to be
there. It is of course no possible to shoot yourself in the foot by
linking to a non-secured external directory, but that's really the
administrator's own fault. There are certainly plenty of ways to shoot
yourself in the foot already with a bad config. :)
Of course, I have no idea if this would be a spec issue or not. With the
finalization process coming up, I'd rather defer that to Craig for a
more expert opinion than my own reading.
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
Re: Extending Server.xml configurability (for
additionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/29/01 2:00 PM, Christopher Cain at ccain@mhsoftware.com 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 be less-than-clean. I'll try to
come up with good arguments why. :-)
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (for additionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
Rick Mann wrote:
>
> on 8/29/01 1:15 PM, Christopher Cain at ccain@mhsoftware.com wrote:
>
> > I'll throw an idea out here, although it may well get shot down for
> > either spec non-compliance, possible security concerns, or just general
> > lack of sex appeal ;-)
>
> I think I'd complain mostly on the grounds of lack of sex appeal. ;-)
>
> Seriously, though, this amounts to tricking Tomcat, I think, and that
> solution does not seem terribly elegant.
It's not really tricking Tomcat at all, IMO. I use soft links for all of
my webapps, since several developers need access to the webapps, but
they don't need access to the Tomcat tree itself. Links are often a very
no-fuss, no-muss solution, and in this case I think it would make alot
of sense (assuming there isn't a spec or technical argument against this
approach).
> BTW, I missed the email that said Tomcat ignores CLASSPATH, but I've
> inferred now that it does (which explains why I couldn't get that approach
> to work).
Tomcat ignores the system CLASSPATH, yes. Several things start to get
really messy if it doesn't use it's own internal classloader.
> So, I'm left with two alternatives that should satisfy my sense of
> aesthetics, but one of which is easier for me (the app developer) to use.
>
> 1) Extend Server.xml to tell Tomcat what additional directories to put in
> the search path.
>
> 2) Add those search paths myself, in my webapp's code. Keep in mind that, as
> Rob S. speculated, I know very little about the ClassLoader mechanism.
That's an awful lot of hacking when you could simply create links in
your WEB-INF/lib directories. I'm not sure how the core developers feel
about my idea, but I would think that you would _definitely_ like it
better than the above. It's an infinitely cleaner approach. You must be
a Windoze guy to hate symlinks that much ;-)
- Christopher
Re: Extending Server.xml configurability (for additional classpaths)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Wouldn't option (3) -- modify the startup shell scripts yourself to
include whatever directories you want -- be easier than either (1) or (2)?
Of course, you're going to be on your own for resolving class loading
difficulties, but that's true under all of these scenarios.
Craig
On Wed, 29 Aug 2001, Rick Mann wrote:
> Date: Wed, 29 Aug 2001 13:41:41 -0700
> From: Rick Mann <rm...@latencyzero.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org, Christopher Cain <cc...@mhsoftware.com>
> Subject: Re: Extending Server.xml configurability (for additional
> classpaths)
>
> on 8/29/01 1:15 PM, Christopher Cain at ccain@mhsoftware.com wrote:
>
> > I'll throw an idea out here, although it may well get shot down for
> > either spec non-compliance, possible security concerns, or just general
> > lack of sex appeal ;-)
>
> I think I'd complain mostly on the grounds of lack of sex appeal. ;-)
>
> Seriously, though, this amounts to tricking Tomcat, I think, and that
> solution does not seem terribly elegant.
>
> BTW, I missed the email that said Tomcat ignores CLASSPATH, but I've
> inferred now that it does (which explains why I couldn't get that approach
> to work).
>
> So, I'm left with two alternatives that should satisfy my sense of
> aesthetics, but one of which is easier for me (the app developer) to use.
>
> 1) Extend Server.xml to tell Tomcat what additional directories to put in
> the search path.
>
> 2) Add those search paths myself, in my webapp's code. Keep in mind that, as
> Rob S. speculated, I know very little about the ClassLoader mechanism.
>
> Solution (1) is my preferred choice, because it localizes the burden of
> expanding the search path to Tomcat, and provides the most security (the
> owner of the Tomcat installation has control of what the webapps have access
> to).
>
> Solution (2) works, assuming it can be done, and assuming I can get educated
> on how to do it. However, it adds work to each and every webapp developer,
> in that they have to write code, rather than adding a line to a config file.
> It also means there will be countless ways of specifying (hard-coding,
> private properties, etc), which complicates people working together.
>
> I'm going to look up the ClassLoader now, and see if I can learn anything.
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
>
>
>
Re: Extending Server.xml configurability (for additionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Rob S." wrote:
>
> > 2) Add those search paths myself, in my webapp's code. Keep in
> > mind that, as
> > Rob S. speculated, I know very little about the ClassLoader mechanism.
>
> 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...
>
> Ok, let me get this straight now. You're saying, "i want to point a web app
> to a location to load jars and classes from." That already exists. You put
> the jars in the WEB-INF/classes and lib directory.
>
> Then the next thing is, "i want them to be visible to more than one web
> app." That already exists too. You put them in $CATALINE_HOME/common/lib
> and classes.
>
> What do you want that Tomcat isn't already giving you? =)
>
> - r
If I understand him correctly, I think what he wants is a way to make
certain shared jars/classes available to multiple webapps, but not
necessaryily all of the webapps ... and without making multiple copies
of the jars/classes. I can kinda understand where he's coming from if it
is a deployment concern, since updating a jar would involve copying it
around to numerous WEB-INF/lib directories. IMHO it's not a huge hassle,
but I also remember, when I first started with Tomcat, thinking that it
was a slightly less-than-clean way to handle that scenerio, and that
there was probably a relatively clean way to do it better.
Now, a) I have a sneaking suspicion that _my_ proposed solution is
somehow going to fly in the face of the spec, b) I am not happy with any
of the other various solutions that I have seen, c) I have long since
come to terms with having multiple copies of my jars where I need shared
but not "webapp global" ones. In other words, this is not really my
"cause celebre". I just thought I'd float an alternative that I could
live with, since I hadn't seen one yet. But since it doesn't really
appeal to Rick anyway, and it's of no consequence to me either way, I'm
going to go back to my SSL docs now :)
Much love, Rob Lobster ;-)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
RE: Extending Server.xml configurability (for additionalclasspaths)
Posted by "Rob S." <rs...@home.com>.
> Correction, put them in $CATALINA_HOME/lib and $CATALINA_HOME/classes to
> make them visible to all web applications but not visible to
> Tomcat internal
> classes.
>
> The common directory lib and classes are visible to both tomcat internal
> classes and web apps.
Oops, thanks for the correction, Glenn! See Rick, I don't understand the
class loading 100% ;)
- r
Re: Extending Server.xml configurability (for additionalclasspaths)
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Rob S." wrote:
>
> > 2) Add those search paths myself, in my webapp's code. Keep in
> > mind that, as
> > Rob S. speculated, I know very little about the ClassLoader mechanism.
>
> 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...
>
> Ok, let me get this straight now. You're saying, "i want to point a web app
> to a location to load jars and classes from." That already exists. You put
> the jars in the WEB-INF/classes and lib directory.
>
> Then the next thing is, "i want them to be visible to more than one web
> app." That already exists too. You put them in $CATALINE_HOME/common/lib
> and classes.
>
Correction, put them in $CATALINA_HOME/lib and $CATALINA_HOME/classes to
make them visible to all web applications but not visible to Tomcat internal
classes.
The common directory lib and classes are visible to both tomcat internal
classes and web apps.
> What do you want that Tomcat isn't already giving you? =)
>
> - r
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
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
RE: Extending Server.xml configurability (foradditionalclasspaths)
Posted by "Rob S." <rs...@home.com>.
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 because what are you are
> proposing skirts dangerously close to encouraging non-portability. As
> the official RI for the specification, the general idea is to think very
> carefully about adding any feature which, if taken advantage of in a
> webapp, would fail to run on another spec-compliant container. Allowing
> admins to specify additional classpaths (in a config file) for a webapp,
> above and beyond what is explicitly provided for in the spec, is a risky
> proposition. Classloading is one of those issues that generally gets a
> lot of thought towards portability before any changes are made.
>
> I'm not saying that there might not be a workable solution to the issue.
> I'm just saying that in proposing changes to server.xml for that
> particular issue, you are probably headed down the wrong path for the
> above reason, primarily. If you aim is to see your solution incorporated
> into the product, that is. Otherwise, go nuts :)
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
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 web.xml file
True, web.xml is defined by the spec and completely out of our hands.
> I propose adding the functionality to the Server.xml file, which I believe to
> be defined by the core developers. If this is not the case, well, it makes
> my request more difficult.
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 because what are you are
proposing skirts dangerously close to encouraging non-portability. As
the official RI for the specification, the general idea is to think very
carefully about adding any feature which, if taken advantage of in a
webapp, would fail to run on another spec-compliant container. Allowing
admins to specify additional classpaths (in a config file) for a webapp,
above and beyond what is explicitly provided for in the spec, is a risky
proposition. Classloading is one of those issues that generally gets a
lot of thought towards portability before any changes are made.
I'm not saying that there might not be a workable solution to the issue.
I'm just saying that in proposing changes to server.xml for that
particular issue, you are probably headed down the wrong path for the
above reason, primarily. If you aim is to see your solution incorporated
into the product, that is. Otherwise, go nuts :)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
RE: Extending Server.xml configurability (foradditionalclasspaths)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 29 Aug 2001, Rob S. wrote:
> Date: Wed, 29 Aug 2001 16:39:38 -0700
> From: Rob S. <rs...@home.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: Extending Server.xml configurability
> (foradditionalclasspaths)
>
> > 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 checked in, his Catalina classloader document, but
> kudos to that thing, at least the old one. It was really good. I started
> working on a class-not-found doc that approached the 'problem' from the
> other angle, as in, "I've go
>
It's not converted into the new-style doc format yet, but my document that
summarizes how Tomcat 4 class loaders are organized is in the
"catalina/docs/dev" directory of the source distribution, and is also
visible by following the documentation links at <http://localhost:8080>
when you start an unmodified Tomcat 4 installation.
Craig
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Paul Speed <ps...@progeeks.com>.
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 of static data
or security permissions or any of that.
-Paul Speed
Rick Mann wrote:
>
> on 8/30/01 11:36 PM, Paul Speed at pspeed@progeeks.com 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 functionality as copying the classes/jars
> into the individual webapp's folders, then that's what I'd do.
>
> However, it's not the same thing. It makes deployment and development more
> difficult, despite the possibility of creating scripts or ant files to
> automate this process, it's still not as easy as being able to put the
> classes in one place once.
>
> If it makes you happy, yes. I want the exact same functionality as copying a
> set of class files/jar files into a subset of installed webapp's directories
> without copying them or making links from one dir to another.
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
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 :)
> So, please accept my apologies for getting frustrated and short. What I
> originally asked for was some guidance into the Catalina sources so that I
> could implement this myself. I'd love it if the feature were incorporated
> into the Tomcat sources permanently, but that was not a requirement (yet,
> anyway ;-) )
>
> on 8/31/01 10:02 AM, Christopher Cain at ccain@mhsoftware.com wrote:
>
> > 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
>
> The problem with this solution is that it implements class sharing in the
> file system, which is neither clean nor necessarily portable. What if I'm
> running catalina on a device that doesn't support symlinks?
AFAIK, there is no "standard" system that TC runs on which does not
support symlinks. For Windows there's always Cygwin, which many people
(myself included :) prefer to run Tomcat in anyway, should you find
yourself stuck in Windoze. I suppose that some of the "embedded" devices
might not do symlinks, since I'm not too familiar with them. I would
consider the above approach to be fairly portable, but that's just me.
As far as class sharing in the file system, the only way in which I can
see it being "unclean" is in the case of shared memory, static
resources, etc. (and in that case, you'll need to separate things out
anyway). Symlinks are _very_ common in the Unix world, and even M$ has
decided to use them in all of their new filesystems (in fact, I saw a
press release last year in which they seemed to imply that they recently
_invented_ them ... LOL!). They are quite a handy little solution in
most cases, and I use them frequently for many things Tomcat.
But of course, this is just one man's opinion, based on my experience
with things similar to what you are facing. If you don't feel that
symlinks are a clean answer, then I'm probably not going to convince you
at this point, so I'll shut up it now :)
> > Paul, like a few others, was obviously just trying to understand what
>
> Sorry, Paul. I took the wording of your message to be "why not just copy the
> classes", which has been suggested several times and is not what I want or
> need. I didn't realize you were actually trying to understand what it is I
> want. That is, however, what I want. Thanks.
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
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 getting frustrated and short. What I
originally asked for was some guidance into the Catalina sources so that I
could implement this myself. I'd love it if the feature were incorporated
into the Tomcat sources permanently, but that was not a requirement (yet,
anyway ;-) )
on 8/31/01 10:02 AM, Christopher Cain at ccain@mhsoftware.com wrote:
> 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
The problem with this solution is that it implements class sharing in the
file system, which is neither clean nor necessarily portable. What if I'm
running catalina on a device that doesn't support symlinks?
> Paul, like a few others, was obviously just trying to understand what
Sorry, Paul. I took the wording of your message to be "why not just copy the
classes", which has been suggested several times and is not what I want or
need. I didn't realize you were actually trying to understand what it is I
want. That is, however, what I want. Thanks.
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Christopher Cain <cc...@mhsoftware.com>.
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 done without even touching the TC code. Modifying the
container to get this "functionality" is silly. If there are
shared-resource/threading issues, then separate jars are required
anyway. This approach will not work for classes, but just throw the
classes in a jar. I really don't understand the issue here. That
creating a few symlinks is somehow messier than needlessly hacking the
container, then trying to maintain that hack every time a new TC is
released?
Paul, like a few others, was obviously just trying to understand what
you were after, and the tone of your reply is completely unnecessary.
Quite frankly, I don't blame him for being confused, because the
question is confusing in its assertation ... what you want can be easily
done without hacking. If you have that much spare time, and enough
distaste for symlinks to make unnecessary hacks, then go for it.
- Christopher
Rick Mann wrote:
>
> on 8/30/01 11:36 PM, Paul Speed at pspeed@progeeks.com 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 functionality as copying the classes/jars
> into the individual webapp's folders, then that's what I'd do.
>
> However, it's not the same thing. It makes deployment and development more
> difficult, despite the possibility of creating scripts or ant files to
> automate this process, it's still not as easy as being able to put the
> classes in one place once.
>
> If it makes you happy, yes. I want the exact same functionality as copying a
> set of class files/jar files into a subset of installed webapp's directories
> without copying them or making links from one dir to another.
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
--
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/30/01 11:36 PM, Paul Speed at pspeed@progeeks.com 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 functionality as copying the classes/jars
into the individual webapp's folders, then that's what I'd do.
However, it's not the same thing. It makes deployment and development more
difficult, despite the possibility of creating scripts or ant files to
automate this process, it's still not as easy as being able to put the
classes in one place once.
If it makes you happy, yes. I want the exact same functionality as copying a
set of class files/jar files into a subset of installed webapp's directories
without copying them or making links from one dir to another.
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Paul Speed <ps...@progeeks.com>.
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 glenn@voyager.apg.more.net 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?
>
> Yes. In particular, I may have a set of classes I want to make available to
> my contexts an no one else's. Or perhaps I own a limited-use license on some
> common classes. Imagine an ISP running Tomcat in a virtual-host
> configuration.
>
> > Do the java classes being shared have static methods and data that needs to be
> > shared across this subset of web applications, but not other web apps?
>
> No, I don't think data need be shared across any contexts, nor do I think
> you'd want to. It really opens up a can of worms to allow contexts to share
> data in memory like that (IMO). I'm assuming individual contexts have
> private data.
>
> > I am trying to determine what you want to accomplish and why, not how you want
> > to do it. Once we know what you want to accomplish it will be easier to
> > determine how to do it within Tomcat 4.
>
> Sure, that makes perfect sense. I don't require being able to extend a
> context's class search path, that just seems to be the most appropriate
> place to do so.
>
> > Comments:
> >
> > If you need to restrict access to an API for security reasons there are ways
> > to do that using the Java SecurityManager configuration and permissions
> > granted in the security policy file.
>
> If you tell me how this is done, I'll let you know if that solves my
> problem. Chances are it does not, because I can't give access to a directory
> to the owner of some contexts, and say "put your common classes in here". I
> have to give access to the CATALINA_HOME/lib|classes dir to every owner of a
> context and I don't want to have to do that.
>
> But I'm always open to suggestion.
>
> Thanks!
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/30/01 4:22 AM, Glenn Nielsen at glenn@voyager.apg.more.net 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?
Yes. In particular, I may have a set of classes I want to make available to
my contexts an no one else's. Or perhaps I own a limited-use license on some
common classes. Imagine an ISP running Tomcat in a virtual-host
configuration.
> Do the java classes being shared have static methods and data that needs to be
> shared across this subset of web applications, but not other web apps?
No, I don't think data need be shared across any contexts, nor do I think
you'd want to. It really opens up a can of worms to allow contexts to share
data in memory like that (IMO). I'm assuming individual contexts have
private data.
> I am trying to determine what you want to accomplish and why, not how you want
> to do it. Once we know what you want to accomplish it will be easier to
> determine how to do it within Tomcat 4.
Sure, that makes perfect sense. I don't require being able to extend a
context's class search path, that just seems to be the most appropriate
place to do so.
> Comments:
>
> If you need to restrict access to an API for security reasons there are ways
> to do that using the Java SecurityManager configuration and permissions
> granted in the security policy file.
If you tell me how this is done, I'll let you know if that solves my
problem. Chances are it does not, because I can't give access to a directory
to the owner of some contexts, and say "put your common classes in here". I
have to give access to the CATALINA_HOME/lib|classes dir to every owner of a
context and I don't want to have to do that.
But I'm always open to suggestion.
Thanks!
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Rick,
I have read all the messages in the thread and have some questions and
comments about what you want to accomplish.
Summary of what you you want to do:
The ability to install jar files in one location that are shared between
some subset of all web applications running in Tomcat, correct?
Questions:
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?
Do the java classes being shared have static methods and data that needs
to be shared across this subset of web applications, but not other web apps?
I am trying to determine what you want to accomplish and why, not how you
want to do it. Once we know what you want to accomplish it will be easier
to determine how to do it within Tomcat 4.
Comments:
If you need to restrict access to an API for security reasons there are ways
to do that using the Java SecurityManager configuration and permissions granted
in the security policy file.
Regards,
Glenn
Rick Mann wrote:
>
> on 8/29/01 5:11 PM, Rob S. at rslifka@home.com 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 can install a new class loader (it seems like I could, by
> installing a new SecurityManager class that I create).
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/29/01 5:11 PM, Rob S. at rslifka@home.com 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 can install a new class loader (it seems like I could, by
installing a new SecurityManager class that I create).
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
RE: Extending Server.xml configurability (foradditionalclasspaths)
Posted by "Rob S." <rs...@home.com>.
> 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? Ugh... you're going to kill portability,
because every time your app is used on a different container, you're going
to have to do the same thing. All for something that Tomcat already gives
you, just not in the *exact* way you want? You're either a very fast
programmer, or you have a lot of free time ;)
My personal opinion - don't bother. It's not a stumbling block. Working
with Ant for 10-15 minutes will solve your 'problem' ;) for eternity,
whereas hours/days working with the TC source will only solve your problem
for Tomcat until it changes.
- r
Re: Extending Server.xml configurability (foradditionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/29/01 4:39 PM, Rob S. at rslifka@home.com 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 probably in whatever iterates through the <Context>
> elements in server.xml. Not too helpful w/out a class tho', sry =/
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).
This requires me to be able to install, from within my webapp, a class
loader that will get used by everyone else. I don't know if that's possible
(sure seems like a security risk).
> Yep, one way could be as children of each <Context> element, because of the
> encapsulation of <Contexts> by <Host> elements, it would be messy to have
> something global where you specify paths since you can have the same
> <Context> path over multiple <Host>S refer to something different.
>
> <Context path="/foo"...>
> <classpath>...</classpath>
> </Content>
That's exactly what I was proposing. I understand the reluctance to do so,
however perhaps the "almost-complete" 2.3 could be modified (yeah, right) to
say that servers should provide a way to extend the class search path.
Anyway, this is what I'd like. Perhaps it won't get included into the source
base, but maybe I can write it up fairly easily for my version.
Thanks!
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
RE: Extending Server.xml configurability (foradditionalclasspaths)
Posted by "Rob S." <rs...@home.com>.
> 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 checked in, his Catalina classloader document, but
kudos to that thing, at least the old one. It was really good. I started
working on a class-not-found doc that approached the 'problem' from the
other angle, as in, "I've go
> I could
> experiment, but in
> what I've read, I not sure I can install a new ClassLoader/SecurityManager
> which will get used by all classes in my web app next time a
> class needs to
> be loaded. Is there a way to specify the ClassLoader used by a context?
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 probably in whatever iterates through the <Context>
elements in server.xml. Not too helpful w/out a class tho', sry =/
> I want to specify a subset of all installed contexts that have access. I
> don't want all installed contexts to have access, just the ones I specify.
>
> Now, to avoid changing the spec, which I understand to be the Servlet 2.2
(2.3)
> spec, which also understand to specify the structure of the
> web.xml file, I
> propose adding the functionality to the Server.xml file, which I
> believe to
> be defined by the core developers. If this is not the case, well, it makes
> my request more difficult.
Yep, one way could be as children of each <Context> element, because of the
encapsulation of <Contexts> by <Host> elements, it would be messy to have
something global where you specify paths since you can have the same
<Context> path over multiple <Host>S refer to something different.
<Context path="/foo"...>
<classpath>...</classpath>
</Content>
but I still think you're better off having Ant or Make worry about it ;)
- r
Re: Extending Server.xml configurability (for additionalclasspaths)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Two quick comments embedded.
On Wed, 29 Aug 2001, Rick Mann wrote:
> Date: Wed, 29 Aug 2001 15:40:52 -0700
> From: Rick Mann <rm...@latencyzero.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Extending Server.xml configurability (for
> additionalclasspaths)
>
> on 8/29/01 3:23 PM, Rob S. at rslifka@home.com 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'd like to understand it. Since then, I've read about the
> ClassLoader, SecurityManager, and System classes. I could experiment, but in
> what I've read, I not sure I can install a new ClassLoader/SecurityManager
> which will get used by all classes in my web app next time a class needs to
> be loaded. Is there a way to specify the ClassLoader used by a context?
>
> > Ok, let me get this straight now. You're saying, "i want to point a web app
> > to a location to load jars and classes from." That already exists. You put
> > the jars in the WEB-INF/classes and lib directory.
>
> Understood.
>
> > Then the next thing is, "i want them to be visible to more than one web
> > app." That already exists too. You put them in $CATALINE_HOME/common/lib
> > and classes.
>
> Didn't realize that one, closer to what I want. In the meantime, that will
> probably solve my problem, however, it's not a general solution (see below).
>
This works, but it also gives access to these classes to Catalina's
internal class loader. This is important for something like servlet.jar
(which has to be the same both inside and outside the container), but not
generally required for applications.
The canonical place to put shared things that are just for application use
is in a JAR file under $CATALNIA_HOME/lib, or in unpacked classes under
$CATALINA_HOME/classes.
> > What do you want that Tomcat isn't already giving you? =)
>
> I want to specify a subset of all installed contexts that have access. I
> don't want all installed contexts to have access, just the ones I specify.
>
That would definitely require adding additional class loaders to the
hierarchy provided by Catalina.
> Now, to avoid changing the spec, which I understand to be the Servlet 2.2
> spec, which also understand to specify the structure of the web.xml file, I
> propose adding the functionality to the Server.xml file, which I believe to
> be defined by the core developers. If this is not the case, well, it makes
> my request more difficult.
>
Well, I've got *one* piece of good news for this discussion -- it's not a
spec issue at all :-).
The only thing the Servlet Specification talks about is /WEB-INF/classes
and /WEB-INF/lib. Any additional capability to support sharing classes
across web applications is (by definition) container specific and is not,
in fact, required to be present at all, in any form. (In other words,
portable applications cannot rely on *anything* outside the web app.)
Since server.xml is a Tomcat thing and not a spec thing, it's definitely
relevant here.
> TIA,
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
>
Craig
Re: Extending Server.xml configurability (for
additionalclasspaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/29/01 3:23 PM, Rob S. at rslifka@home.com 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'd like to understand it. Since then, I've read about the
ClassLoader, SecurityManager, and System classes. I could experiment, but in
what I've read, I not sure I can install a new ClassLoader/SecurityManager
which will get used by all classes in my web app next time a class needs to
be loaded. Is there a way to specify the ClassLoader used by a context?
> Ok, let me get this straight now. You're saying, "i want to point a web app
> to a location to load jars and classes from." That already exists. You put
> the jars in the WEB-INF/classes and lib directory.
Understood.
> Then the next thing is, "i want them to be visible to more than one web
> app." That already exists too. You put them in $CATALINE_HOME/common/lib
> and classes.
Didn't realize that one, closer to what I want. In the meantime, that will
probably solve my problem, however, it's not a general solution (see below).
> What do you want that Tomcat isn't already giving you? =)
I want to specify a subset of all installed contexts that have access. I
don't want all installed contexts to have access, just the ones I specify.
Now, to avoid changing the spec, which I understand to be the Servlet 2.2
spec, which also understand to specify the structure of the web.xml file, I
propose adding the functionality to the Server.xml file, which I believe to
be defined by the core developers. If this is not the case, well, it makes
my request more difficult.
TIA,
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam
RE: Extending Server.xml configurability (for additionalclasspaths)
Posted by "Rob S." <rs...@home.com>.
> 2) Add those search paths myself, in my webapp's code. Keep in
> mind that, as
> Rob S. speculated, I know very little about the ClassLoader mechanism.
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...
Ok, let me get this straight now. You're saying, "i want to point a web app
to a location to load jars and classes from." That already exists. You put
the jars in the WEB-INF/classes and lib directory.
Then the next thing is, "i want them to be visible to more than one web
app." That already exists too. You put them in $CATALINE_HOME/common/lib
and classes.
What do you want that Tomcat isn't already giving you? =)
- r
Re: Extending Server.xml configurability (for additional
classpaths)
Posted by Rick Mann <rm...@latencyzero.com>.
on 8/29/01 1:15 PM, Christopher Cain at ccain@mhsoftware.com wrote:
> I'll throw an idea out here, although it may well get shot down for
> either spec non-compliance, possible security concerns, or just general
> lack of sex appeal ;-)
I think I'd complain mostly on the grounds of lack of sex appeal. ;-)
Seriously, though, this amounts to tricking Tomcat, I think, and that
solution does not seem terribly elegant.
BTW, I missed the email that said Tomcat ignores CLASSPATH, but I've
inferred now that it does (which explains why I couldn't get that approach
to work).
So, I'm left with two alternatives that should satisfy my sense of
aesthetics, but one of which is easier for me (the app developer) to use.
1) Extend Server.xml to tell Tomcat what additional directories to put in
the search path.
2) Add those search paths myself, in my webapp's code. Keep in mind that, as
Rob S. speculated, I know very little about the ClassLoader mechanism.
Solution (1) is my preferred choice, because it localizes the burden of
expanding the search path to Tomcat, and provides the most security (the
owner of the Tomcat installation has control of what the webapps have access
to).
Solution (2) works, assuming it can be done, and assuming I can get educated
on how to do it. However, it adds work to each and every webapp developer,
in that they have to write code, rather than adding a line to a config file.
It also means there will be countless ways of specifying (hard-coding,
private properties, etc), which complicates people working together.
I'm going to look up the ClassLoader now, and see if I can learn anything.
------------------------------------------------------------
Roderick Mann rmann @ latencyzero.com.sansspam