Re: Extending Server.xml configurability (for additionalclasspaths)
Two quick comments embedded. On Wed, 29 Aug 2001, Rick Mann wrote: Date: Wed, 29 Aug 2001 15:40:52 -0700 From: Rick Mann [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Extending Server.xml configurability (for additionalclasspaths) 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'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)
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)
Rick Mann wrote: on 8/28/01 9:08 PM, Rob S. at [EMAIL PROTECTED] 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)
Rick Mann wrote: on 8/29/01 1:15 PM, Christopher Cain at [EMAIL PROTECTED] 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 additionalclasspaths)
So, it seems that you're saying that I don't understand the class loading mechanism. What I'm saying is that right now, there's a way to get the classes you want into the web app(s) you want. Is it really hard to have Ant or Make create a .war with the right file(s) in it? Personally, I'm always for less work than more. Having to worry about moving your app to a new container is more work than less, when placing everything in WEB-INF/lib and /classes works just fine. I mean, how big are the .jar files we're dealing with here? 4GB? To make portability not an issue, it would have to be spec'd in, and like Craig said, this isn't the place for maybe the spec should say... discussions since the experts are elsewhere. Although there are lots of experts here of course =) - r
RE: Extending Server.xml configurability (for additionalclasspaths)
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 additionalclasspaths)
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)
on 8/28/01 2:13 AM, Reilly, John at [EMAIL PROTECTED] wrote: I don't understand why you would want this - doesn't the WEB-INF/lib and WEB-INF/classes not already provide seperation of classpaths for the various webapps. Am I missing something? Well, I need to share a class tree and/or .jar files among a handful of separate contexts. The currently available options are not really sufficient for my needs: 1. I can copy the classes/.jar files to each context's WEB-INF directory. 2. I can add a separate directory containing my classes and add that directory to the environment's CLASSPATH (this has, so far, not worked). I really want to be able to take a stock installation of Tomcat, add our Server.xml file and context directories, and start the server. Solution (1) makes version control difficult (as Douglas notes below), and Solution (2), aside from not working yet for me, means scripts have to be changed, and is possibly different for different platforms. on 8/28/01 11:51 AM, Douglas Seifert at [EMAIL PROTECTED] wrote: Wouldn't it be better to use META-INF/MANIFEST.MF to specify additional classpath information via the Class-Path: manifest header in a .war archive. I know disk space is cheap and it isn't a problem to copy jars to multiple locations, but it does make version control and updates of jars kind of a pain. Using the Class-Path: manifest header allows a system administrator to keep jars in a central place for easy control, while at the same time maintaining the compartmentalization of classpath space that you get with the web application class loader. It would be easy enough to extend the web app class loader to parse out the Class-Path: headers in any META-INF/MANIFEST.MF files it finds in its repository directories and/or jars/zips. If I have time, I will look at the source tonight and see if I can't whip up a patch ... It seems to me that using existing classpath extension mechanisms is better than adding a non-spec extension to server.xml ... Ideally, I'd be able to specify additional class paths in the web.xml file, but that requires changing a spec. However, I was under the impression that the server.xml file was defined by Tomcat, and so could be extended. Using the manifest might be an acceptable solution; I didn't know about that. However, I have these questions: 1) can the manifest be placed in an open or expanded .war archive (I'm not sure of the terminology; whatever it is where have separate folders, rather than a single .war file). 2) can this manifest be easily edited to add/change/remove class paths (i.e. with a regular text editor)? I'm not 100% sure that extending the web.xml file or using the manifest are necessarily the best places for this, because it means that a context can extend its reach, so to speak, without intervention from anyone else. This is potentially a security risk, since someone might install a webapp without considering what it might touch. If the control of additional classpaths is placed within the context's dir contents, perhaps a flag in the Server.xml file indicating that a context is allowed to extend its reach should be considered as well. Thanks, Douglas, for looking into this for me. I really appreciate it. Roderick Mann rmann @ latencyzero.com.sansspam
