RE: Resources for a Context
I've implemented my own DirContext, which extends FileDirContext, and allows one to specify any number of directories on the webapp's classpath. The solution works wonderfully, once I hacked around what I think are bugs in Tomcat. It seems that when you specify your own Resources entry for a Context, Tomcat does things in slightly the wrong order during initialization. I have the following structure in my server.xml: Host ... Context ... Resources className=com.my.dirContext ... / /Context /Host During the parsing of the server.xml file, setResources() is called on the StandardContext object, passing in an instance of my custom DirContext object. At this point, Tomcat creates a ProxyDirContext, wrapping my custom DirContext. During the initialization of the ProxyDirContext, the host is not properly determined and set in the environment. As far as I can tell, this is because at this point in the initialization, the Context entry has not had its parent set yet. This causes all kinds of problems later, since the ProxyDirContext will improperly determine the path to resources if it doesn't have a valid entry for host in its environment. I'm using TC 4.0.6, and have gotten around this by hacking StandardContext.getBasePath() and ContainerBase.setParent(). Has anyone else seen this problem? Is it fixed in a later version? Dave -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 5:30 PM To: Tomcat Users List Subject: RE: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 17:09:44 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. #2 makes sense to me. Basing your class on the existing code in FileDirContext (in particular, you'll probably want to subclass BaseContext), but allowing it to be configured with multiple directories, should keep you very insulated from the rest of the Tomcat internals. The rest of Tomcat just works through DirContext. You'll have to decide what to do when there's more than one of the directories that have a file or subdirectory of the same name -- perhaps in the order that the directories are configured. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Resources for a Context
Howdy, Can you please illustrate a possible use for this feature before you start coding it? A use case which can't be addressed by the servlet spec, that is. Right now, I doubt such a contribution would be accepted into tomcat's core, so you may not want to waste time writing it at all ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: David Keyes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 5:10 PM To: Tomcat Users List Subject: RE: Resources for a Context I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. The only reason that I'm spending so much energy on this is that for very large web applications that are not structured as a webapp, which I think is rather common, it would be a HUGE aid in debugging to be able to pull something like this off. The code/compile/debug cycle gets a bit cumbersome when one is constantly redeploying large apps. I think for deployment the spec works just fine. Thanks again for your help, and all of your excellent work. Dave Keyes -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 4:24 PM To: Tomcat Users List Subject: RE: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 15:53:22 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context So what mechanism would you suggest for making MORE than one Resources directory available for a Context? * Modify Tomcat to support multiple resources directories (It's open source :-). Note that you're violating the letter and spirit of the servlet spec's requirements on webapp organization, so it would be problematic accepting such a change back into Tomcat's core. * Use symbolic links (which doesn't help Windows users much). * Build deployment scripts that copy everything you need in the webapp together. Craig -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
As I've been eluding to in my earlier posts, the primary place where this makes sense is in development environments, and that's once place where Tomcat is used extensively. I'm not necessarily advocating modification of the spec, all though I can imagine that there are real life scenarios where something like this might be very useful. In our development environment, we have many small modules that can be combined into a single webapp. We can pick and choose from various modules at build time to produce a distributable webapp. I think that this is a rather common source configuration in large web projects. It sometimes simply does NOT make sense to organize your code within a repository as a monolithic webapp. When you have structure such as ours, it can become very cumbersome to rebuild and deploy the webapp every time that you want to see changes in a few jsp/html/css/script files. Granted, an ant script or batch file CAN do this, but it is heavy, and quite frankly, a pain. Tomcat allows one to replace the classloader used by a container (i.e., a Context), and we are doing that with one that points back to the various class repositories for our modules. Now we just need to be able to do the same thing for static resources and we will be all set. I'm going to explore the idea of creating a new DirContext. Whether or not this is accepted back into the core is really not a huge issue to me, but I'm quite certain that there are others that would find the same thing useful. Does this make sense to anyone else? Dave Keyes -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 9:00 AM To: Tomcat Users List Subject: RE: Resources for a Context Howdy, Can you please illustrate a possible use for this feature before you start coding it? A use case which can't be addressed by the servlet spec, that is. Right now, I doubt such a contribution would be accepted into tomcat's core, so you may not want to waste time writing it at all ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: David Keyes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 5:10 PM To: Tomcat Users List Subject: RE: Resources for a Context I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. The only reason that I'm spending so much energy on this is that for very large web applications that are not structured as a webapp, which I think is rather common, it would be a HUGE aid in debugging to be able to pull something like this off. The code/compile/debug cycle gets a bit cumbersome when one is constantly redeploying large apps. I think for deployment the spec works just fine. Thanks again for your help, and all of your excellent work. Dave Keyes -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 4:24 PM To: Tomcat Users List Subject: RE: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 15:53:22 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context So what mechanism would you suggest for making MORE than one Resources directory available for a Context? * Modify Tomcat to support multiple resources directories (It's open source :-). Note that you're violating the letter and spirit of the servlet spec's requirements on webapp organization, so it would be problematic accepting such a change back into Tomcat's core. * Use symbolic links (which doesn't help Windows users much). * Build deployment scripts that copy everything you need in the webapp together. Craig -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED
RE: Resources for a Context
Howdy, Very interesting. Thanks for sharing. Personally, we have a very similar development environment. Many smaller modules (with possibly different versions of each module) that we pick and choose at build time. We've chosen to create Ant scripts to handle (re)building, (re)deploying, and (re)starting tomcat to handle this. We've found the ant script creation to be easy, painless, and well worth the time. They're fairly small, compact, easy to debug, understand, and run. We have a variety of development servers, IDEs, and methodologies, and the ant scripts work everything. Moreover, we didn't want to delve into the complexities of custom classloaders and custom JNDI resource implementations. Good luck with your implementation. I'd be interested in seeing the final result once you're done, and hearing comments on how it works out in your organization. Yoav Shapira Millennium ChemInformatics -Original Message- From: David Keyes [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 9:59 AM To: Tomcat Users List Subject: RE: Resources for a Context As I've been eluding to in my earlier posts, the primary place where this makes sense is in development environments, and that's once place where Tomcat is used extensively. I'm not necessarily advocating modification of the spec, all though I can imagine that there are real life scenarios where something like this might be very useful. In our development environment, we have many small modules that can be combined into a single webapp. We can pick and choose from various modules at build time to produce a distributable webapp. I think that this is a rather common source configuration in large web projects. It sometimes simply does NOT make sense to organize your code within a repository as a monolithic webapp. When you have structure such as ours, it can become very cumbersome to rebuild and deploy the webapp every time that you want to see changes in a few jsp/html/css/script files. Granted, an ant script or batch file CAN do this, but it is heavy, and quite frankly, a pain. Tomcat allows one to replace the classloader used by a container (i.e., a Context), and we are doing that with one that points back to the various class repositories for our modules. Now we just need to be able to do the same thing for static resources and we will be all set. I'm going to explore the idea of creating a new DirContext. Whether or not this is accepted back into the core is really not a huge issue to me, but I'm quite certain that there are others that would find the same thing useful. Does this make sense to anyone else? Dave Keyes -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 9:00 AM To: Tomcat Users List Subject: RE: Resources for a Context Howdy, Can you please illustrate a possible use for this feature before you start coding it? A use case which can't be addressed by the servlet spec, that is. Right now, I doubt such a contribution would be accepted into tomcat's core, so you may not want to waste time writing it at all ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: David Keyes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 5:10 PM To: Tomcat Users List Subject: RE: Resources for a Context I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. The only reason that I'm spending so much energy on this is that for very large web applications that are not structured as a webapp, which I think is rather common, it would be a HUGE aid in debugging to be able to pull something like this off. The code/compile/debug cycle gets a bit cumbersome when one is constantly redeploying large apps. I think for deployment the spec works just fine. Thanks again for your help, and all of your excellent work. Dave Keyes -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 4:24 PM To: Tomcat Users List Subject: RE: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 15:53:22 -0500 From: David Keyes [EMAIL
RE: Resources for a Context
Howdy, I assume you've read this, right? http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.htm l Context path=/myapp docBase=C:/test/ Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj1/web / Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj2/web / /Context I'm confused about what the above is trying to do. What is the design goal here? Perhaps if we start with that, we can find out the cleanest, simplest, most portable way to address it. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
To serve http://localhost:8080/myapp/index.html, all you need is the /myapp Context element. You don't need either of those Resources elements. Using them just confuses Tomcat. I'm not sure what you want to do...if you want to put index.html in c:\dev\proj1\web and have that be /myapp/index.html, then you need to make c:\dev\proj1\web the docBase for your /myapp Context. From: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/resources.html The Resources element represents the web application static resources, from which classes will be loaded, HTML, JSP and the other static files will be served. This allows the webapp to reside on various mediums other than the filesystem, like compressed in a WAR file, in a JDBC database, or in a more advanced versioning repository. A Resources element MAY be nested inside a Context component. If it is not included, a default filesystem based Resources will be created automatically, which is sufficient for most requirements. John -Original Message- From: David Keyes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 2:27 PM To: [EMAIL PROTECTED] Subject: Resources for a Context I am confused about what exactly Resource entries are supposed to accomplish in Tomcat. I have the following entry in my server.xml file for Tomcat 4.0.6: Context path=/myapp docBase=C:/test/ Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj1/web / Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj2/web / /Context If the directory c:/dev/proj1/web/ has a file called index.html in it, I would expect loading the url http://localhost:8080/myapp/index.html to return the file c:/dev/proj1/web/index.html. Am I reading this completely wrong? This all seems to be a moot point anyway, since whenever I make a Resources entry within a Context element, I get the following error from Tomcat at startup: java.lang.IllegalArgumentException: Document base C:\usr\jakarta-tomcat-4.0.6\C:\test does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirC ontext.java:187) at org.apache.catalina.core.StandardContext.setResources(Standard Context.java:1108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.util.xml.AddChild.end(XmlMapper.java:811) at org.apache.catalina.util.xml.XmlMapper.matchEnd(XmlMapper.java:419) at org.apache.catalina.util.xml.XmlMapper.endElement(XmlMapper.java:119) at org.xml.sax.helpers.XMLReaderAdapter.endElement(XMLReaderAdapt er.java:347) at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403) at org.apache.xerces.validators.common.XMLValidator.callEndElemen t(XMLValidator.java:1550) at org.apache.xerces.framework.XMLDocumentScanner.scanElement(XML DocumentScanner.java:1809) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatch er.dispatch(XMLDocumentScanner.java:1182) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDo cumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:314) at javax.xml.parsers.SAXParser.parse(SAXParser.java:253) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228) at org.apache.catalina.startup.Catalina.start(Catalina.java:725) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) java.lang.NullPointerException at org.apache.catalina.startup.Catalina.start(Catalina.java:794) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at
Re: Resources for a Context
On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 14:27:24 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Resources for a Context I am confused about what exactly Resource entries are supposed to accomplish in Tomcat. I have the following entry in my server.xml file for Tomcat 4.0.6: Context path=/myapp docBase=C:/test/ Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj1/web / Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj2/web / /Context In general, you should never mess with the Resources element at all -- Tomcat's defaults will work fine unless you have to do something really crazy. And, of course, even if you *are* that crazy :-), having two of these is going to fail miserably anyway, since there's only one resources property on a Context. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
So what mechanism would you suggest for making MORE than one Resources directory available for a Context? I understand that this may not be supported currently within Tomcat, but it would be REALLY useful to be able to do it for development purposes. If you're interested in my reasoning, please see an earlier message that I posted today with the subject Anybody VIRTUAL CONTEXT. Thanks for your help. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 3:32 PM To: Tomcat Users List Subject: Re: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 14:27:24 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Resources for a Context I am confused about what exactly Resource entries are supposed to accomplish in Tomcat. I have the following entry in my server.xml file for Tomcat 4.0.6: Context path=/myapp docBase=C:/test/ Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj1/web / Resources className=org.apache.naming.resources.FileDirContext docBase=c:/dev/proj2/web / /Context In general, you should never mess with the Resources element at all -- Tomcat's defaults will work fine unless you have to do something really crazy. And, of course, even if you *are* that crazy :-), having two of these is going to fail miserably anyway, since there's only one resources property on a Context. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 15:53:22 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context So what mechanism would you suggest for making MORE than one Resources directory available for a Context? * Modify Tomcat to support multiple resources directories (It's open source :-). Note that you're violating the letter and spirit of the servlet spec's requirements on webapp organization, so it would be problematic accepting such a change back into Tomcat's core. * Use symbolic links (which doesn't help Windows users much). * Build deployment scripts that copy everything you need in the webapp together. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. The only reason that I'm spending so much energy on this is that for very large web applications that are not structured as a webapp, which I think is rather common, it would be a HUGE aid in debugging to be able to pull something like this off. The code/compile/debug cycle gets a bit cumbersome when one is constantly redeploying large apps. I think for deployment the spec works just fine. Thanks again for your help, and all of your excellent work. Dave Keyes -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 4:24 PM To: Tomcat Users List Subject: RE: Resources for a Context On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 15:53:22 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context So what mechanism would you suggest for making MORE than one Resources directory available for a Context? * Modify Tomcat to support multiple resources directories (It's open source :-). Note that you're violating the letter and spirit of the servlet spec's requirements on webapp organization, so it would be problematic accepting such a change back into Tomcat's core. * Use symbolic links (which doesn't help Windows users much). * Build deployment scripts that copy everything you need in the webapp together. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Resources for a Context
On Wed, 22 Jan 2003, David Keyes wrote: Date: Wed, 22 Jan 2003 17:09:44 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Resources for a Context I would be happy to make any modifications that would be required. I've spent a bit of time looking around at the source already, but I'm not sure what the best approach would be. It would be nice if it could be done in a plugin kind of way, but after looking around a bit, it seems that the concept of a single physical directory as a docbase is pretty ingrained (comments?). So far, I've looked at the following: 1. Writing a new catalina Context implementation 2. Writing a new jndi DirContext implementation, that would be configurable to take multiple directories Of those two, I think #2 makes the most sense, but I have doubts as to whether it would solve the problem. What I'm afraid of is that the changes required are peppered throughout the Tomcat codebase. Any pointers that you could give me to get me started in the right direction initially would be hugely appreciated. #2 makes sense to me. Basing your class on the existing code in FileDirContext (in particular, you'll probably want to subclass BaseContext), but allowing it to be configured with multiple directories, should keep you very insulated from the rest of the Tomcat internals. The rest of Tomcat just works through DirContext. You'll have to decide what to do when there's more than one of the directories that have a file or subdirectory of the same name -- perhaps in the order that the directories are configured. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
