RE: Cookie handling in IE6 and session handling of tomcat 4.1.24
IN GENERAL: For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and if two different J2EE app servers are hosting those domains, the following will be true, assuming that the two appservers create session cookies that are identical except for the domain (note that a cookie consists of: name, domain, path, expiration): * If a user, running Internet Explorer, uses J2EE apps running on both domains, causing a session to be established on both domains simultaneously, the client accessing the application running in domain B will not be able to access a session established in domain B. This is due to the fact that IE orders cookies from least-specific to most-specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server that looks for the FIRST cookie named JSESSIONID will be susceptible to this problem. EXAMPLE: In our case, tomcat was serving up JSPs on x.com, causing a J2EE servlet session to be created when that page was loaded. Immediately after hitting x.com, w.x.com was being loaded, which also caused a session to be created. Both sessions were being identified by cookies set in the client browser. The cookies both had an ID of JSESSIONID, with an identical path. The only difference between the cookies was the domain (one was x.com, and the other was w.x.com). When interacting with the app on w.x.com, each request included an HTTP header specifying client-side cookies. In that header, the JSESSIONID created by x.com was ordered BEFORE the JSESSIONID created by w.x.com. The appserver on domain w.x.com was consequently attempting to find the session that had been created on x.com, and since it could not, was creating a new session with each request. Dave Keyes -Original Message- From: Suraj Berwal [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 11:00 AM To: Tomcat Users List Subject: Cookie handling in IE6 and session handling of tomcat 4.1.24 dear tim, i am facing a similar problem with my clients on IE6.0 regarding the session handling using tomcat 4.1.24. Actually the data is getting swapped for users there. can you please elaborate on the info you have posted about cookie problem in IE and how it can affect the session handling in tomcat. i have a singlw webapp and the tomcat is running on Standalone mode. re, suraj berwal Do you have other webapps? I thought I recall at one time, some version of IE did send cookies in the correct order. This can hurt session handling in tomcat. -Tim Billy Ng wrote: Hi folks; I have a customer complains the IE 6 sp1 times out the tomcat session way before the tomcat default session time out settings. I tried to reproduce it but I can't. Have anybody experienced this? Billy Ng - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cookie handling in IE6 and session handling of tomcat 4.1.24
Unfortunately, IE does NOT disobey the spec. The spec is ambiguous about what to do in this scenario, and Microsoft (big surprise) just chose to do things differently than everyone else. The spec (RFC 2109) says in section 4.3.4: If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. *** Ordering with respect to other attributes (e.g., Domain) is unspecified.*** I added the emphasis. I don't see a good solution to the problem, other than removing the mandate in the servlet spec that says JSESSIONID must be used to identify the cookie... Dave -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:29 PM To: David Keyes Cc: Tomcat Users List Subject: RE: Cookie handling in IE6 and session handling of tomcat 4.1.24 On Thu, 26 Jun 2003, David Keyes wrote: Date: Thu, 26 Jun 2003 08:59:46 -0400 From: David Keyes [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Cookie handling in IE6 and session handling of tomcat 4.1.24 IN GENERAL: For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and if two different J2EE app servers are hosting those domains, the following will be true, assuming that the two appservers create session cookies that are identical except for the domain (note that a cookie consists of: name, domain, path, expiration): * If a user, running Internet Explorer, uses J2EE apps running on both domains, causing a session to be established on both domains simultaneously, the client accessing the application running in domain B will not be able to access a session established in domain B. This is due to the fact that IE orders cookies from least-specific to most-specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server that looks for the FIRST cookie named JSESSIONID will be susceptible to this problem. EXAMPLE: In our case, tomcat was serving up JSPs on x.com, causing a J2EE servlet session to be created when that page was loaded. Immediately after hitting x.com, w.x.com was being loaded, which also caused a session to be created. Both sessions were being identified by cookies set in the client browser. The cookies both had an ID of JSESSIONID, with an identical path. The only difference between the cookies was the domain (one was x.com, and the other was w.x.com). When interacting with the app on w.x.com, each request included an HTTP header specifying client-side cookies. In that header, the JSESSIONID created by x.com was ordered BEFORE the JSESSIONID created by w.x.com. The appserver on domain w.x.com was consequently attempting to find the session that had been created on x.com, and since it could not, was creating a new session with each request. You probably want to address this as a bug report against Tomcat: http://nagoya.apache.org/bugzilla/ However, I can't see a lot of motivation to make Tomcat disobey the specs just because IE does. The real issue is that the incoming cookies only have names and values; there is no extra information with which to disambiguate them. Changing the current take the first one policy woud break Tomcat for all users on all browsers when you have context paths nested (instead of or in addition to domains), so it is not a general purpose solution. But it's an issue for the Tomcat developers to hash out. I'm not an active one any more (although I try to keep an eye on things there). Dave Keyes Craig -Original Message- From: Suraj Berwal [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 11:00 AM To: Tomcat Users List Subject: Cookie handling in IE6 and session handling of tomcat 4.1.24 dear tim, i am facing a similar problem with my clients on IE6.0 regarding the session handling using tomcat 4.1.24. Actually the data is getting swapped for users there. can you please elaborate on the info you have posted about cookie problem in IE and how it can affect the session handling in tomcat. i have a singlw webapp and the tomcat is running on Standalone mode. re, suraj berwal Do you have other webapps? I thought I recall at one time, some version of IE did send cookies in the correct order. This can hurt session handling in tomcat. -Tim Billy Ng wrote: Hi folks; I have a customer complains the IE 6 sp1 times out the tomcat session way before the tomcat default session time out settings. I tried to reproduce it but I can't. Have anybody experienced this? Billy Ng - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp:include semantics?
OK, oops, the path should have been relative to the webapp. But now I'm seeing a different set of problems. My original call is to a servlet /myapp/myservlet/param1/param2. That servlet forwards to a jsp /myapp/wrapper.jsp. The jsp then includes the same servlet that called it, but changes the path, e.g., jsp:include page=/myapp/myservlet/newparam1/newparam2 flush=true/ When I set a breakpoint, in the servlet, it seems as if the request object is the same request object as the one from the original servlet. Specifically, the URI doesn't reflect the changes that were made in the jsp. It's spooky... Dave -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 3:37 PM To: Tomcat Users List Subject: Re: jsp:include semantics? On Wed, 5 Feb 2003, David Keyes wrote: Date: Wed, 5 Feb 2003 12:59:41 -0500 From: David Keyes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FW: jsp:include semantics? Hello. What are the semantics of jsp:include in Tomcat 4.0.x? It seems to me that if I jsp:include another jsp, things work fine. But if I try to include a servlet (one that was registered in my web.xml, e.g. url == /mywebapp/myservlet) the servlet is treated as if it were a traditional resource (that is, Tomcat tries to find a file named /mywebapp/myservlet), which of course can't be found since it doesn't exist. Is this behaviour correct? Should I be bugging the Jasper people about this one? Are there any non-standards-breaking ways of getting around this? The path you specify as an argument to jsp:include has to be context relative. If /mywebapp is the context path of your webapp, then you should say: jsp:include path=/myservlet .../ instead of: jsp:include path=/mywebapp/myservlet .../ In addition, if you're using a web connector (instead of Tomcat standalone), you'll need to tell it to forward /myservlet paths to Tomcat -- this would also affect a direct requests to your servlet from a browser. Thanks... Dave Keyes Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: jsp:include semantics?
Hello. What are the semantics of jsp:include in Tomcat 4.0.x? It seems to me that if I jsp:include another jsp, things work fine. But if I try to include a servlet (one that was registered in my web.xml, e.g. url == /mywebapp/myservlet) the servlet is treated as if it were a traditional resource (that is, Tomcat tries to find a file named /mywebapp/myservlet), which of course can't be found since it doesn't exist. Is this behaviour correct? Should I be bugging the Jasper people about this one? Are there any non-standards-breaking ways of getting around this? Thanks... Dave Keyes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP's in other directories
If what you REALLY want to do is make your webapp be able to access resources outside of the webapp structure, and if you want to be non-J2EE, then you can write your own implementation of a JNDI DirContext, and allow it to find resources any way that you want. You just have to register that DirContext implementation using the Resources element for your context... I've done this very thing to allow my Tomcat development environment to access jsp/html/css/etc files from MANY different locations outside of the webapp structure. It works great for a development environment where all of your resources aren't in the shape of a webapp, but you want to be able to have a context running against them as you work... ;) Dave Keyes -Original Message- From: Ming Zhao [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 1:00 PM To: Tomcat Users List Subject: Re: JSP's in other directories You use JK2 as the connector between Apache and Tomcat? If so, you can map your jsp in the workers2.properties. Still I have a question: how can you set the main directory of your page files and call Tomcat to deal with jsp files under your main directory? --- Erik Price [EMAIL PROTECTED] wrote: Nicholas J Campbell wrote: Hi, I have a question, I want to be able to access JSP pages that are outside of the web-inf directory setup by tomcat...I do not know how to do it, obviously. I have Apache 2 installed and use that at my main server and then am running tomcat for the purposes of Servlets and JSP's and I want to know what I have to do to make myself be able to access a jsp page that is in a directory like c:\site You should generally be able to refer to resources in your site by using a path relative to the context. For instance, I have the following site structure: /MyApp index.jsp main.jsp others.jsp /WEB-INF /classes /com /ptc /myapp SomeClass.class OtherClass.class /server SomeServlet.class OtherServlet.class /lib somejar.jar To access one of my JSPs from another JSP, I just use a relative path in the HTML part of the JSP. To forward to one of my JSPs from a servlet, I use the following line of code: String TARGET_JSP = /main.jsp; javax.servlet.ServletContext sc = this.getServletContext(); javax.servlet.RequestDispatcher rd = sc.getRequestDispatcher(TARGET_JSP); rd.forward(); That's one way to do it, even though the servlet is in /MyApp/WEB-INF/classes and the JSP is in /MyApp. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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
Anyone VIRTUAL WEBAPP?
I am working on a project that involves creating a web application. Within our build environment, the webapp does not exist in the standard webapp structure. For example, we have servlets/jsp/html/images/etc in various directories that need to be merged into the standard webapp structure (we use an ant script for this) before they can be deployed and run on an app server (i.e. tomcat). The problem with this is that it really stinks to run a hefty ant script every time that I want to see a minor change in a JSP. So here's what I would like to do in my development environment (wich happens to be Eclipse). It involves two parts: 1. Create a development context class loader. Sysdeo has already written one of these that allows multiple arbitrary paths to be added to the standard set (WEB-INF/classes and WEB-INF/lib) supported by the servlet spec. This works reasonably well, and allows me to load servlets/resources/etc from the various places that they exist within my development environment. No copying/moving/etc. required! 2. The next thing required would be to have a tomcat Context that would look in various non-standard places for requested resources such as JSPs, html files, images, etc. Essentially, I would like to have tomcat look in a series of directories for a requested resource (within a single Context), rather than just in the docBase. For example, if the url http://localhost:8080/myapp/index.html were requested, I would like tomcat to look in c:\dev\module1\web, c:\dev\module2\web, c:\dev\moduleN\web, etc. The process would stop as soon as the resource was found. Has anyone seen something like this already implemented? If not, are there any suggestions on where I would start to do this myself? I was thinking that I might be able to simply extend the StandardContext in Catalina, but it looks like things are pretty hard coded around the idea of a single docBase directory. Other people have to have similar development structures, so how are others doing this? Dave Keyes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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(FileDirContext.java:187) at org.apache.catalina.core.StandardContext.setResources(StandardContext.java:1108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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(XMLReaderAdapter.java:347) at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403) at org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1550) at org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1809) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1182) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.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(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- 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
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]
