RE: forwarding across contexts?
Hi, In short, how does one deploy a war file such that it looks for content (/images/whatever.gif) in a configurable location in the file system? Configure the server to serve that WAR file with a context path of (the empty string). This can be done in tomcat in three ways: - Add a Context entry in conf/server.xml whose path= and docBase is your WAR - Add an xml file with the Context tag to conf/[engine name]/[host name] (same path and docBase) - Put same XML file as above in your WAR file's META-INF directory instead of under the conf directory (tomcat 5 only). Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: forwarding across contexts?
Thanks once again. This is very helpful. Now here's what I really want (it never ends, does it): Is there a way, within a single context, to separate out the static content to some other file system location. I'd like to be able to deploy my war file with library jars, configuration info, classes, etc., into the safe location within the jboss deploy directory. But, I'd like to have all of my static content (again, /images/whatever.gif) elsewhere on the file system. I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. So is there a way to accomplish this separation within a single context? Many, many thanks. It's amazing how, even with a stack of books and google and jakarta and all, there's no substitute for talking with people. Fred At 07:37 AM 5/11/2004, you wrote: Hi, In short, how does one deploy a war file such that it looks for content (/images/whatever.gif) in a configurable location in the file system? Configure the server to serve that WAR file with a context path of (the empty string). This can be done in tomcat in three ways: - Add a Context entry in conf/server.xml whose path= and docBase is your WAR - Add an xml file with the Context tag to conf/[engine name]/[host name] (same path and docBase) - Put same XML file as above in your WAR file's META-INF directory instead of under the conf directory (tomcat 5 only). Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: forwarding across contexts?
Hi, Is there a way, within a single context, to separate out the static content to some other file system location. Of course, there are many ways, none of them advised. You want to keep your webapp as a whole, that's the whole point of a WAR file. You can symlink (at the filesystem level) or use normal HTTP linking to access your static content. But you can't symlink in a WAR, so... I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. And I agree with Justin, just to be clear. I wasn't advocating anything different from what he said, just showing you that it can technically be done. If crossContext forwards are the worst design choices on this list, we'll be in great shape. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: forwarding across contexts?
Yoav, Let me describe a bit about our application, just in case you (or anyone else) have some specific advice. My client is a publisher, and the bulk of the site will be many thousands of published articles and associated content such as figure, tables, etc. The HTML content, however, will be served by tomcat, since it has some dynamic components. This is why it's not practical to bundle everything into a war file. Instead, I need tomcat to point to the file system where many users will be building the site. On the other hand, the war file can easily contain the java infrastructure (struts, velocity, configuration information, etc.). I'd like to be able to keep the small war file, hot deploy, etc., but have the raw content (static and otherwise) live elsewhere. Given that, would you solve it with multiple contexts? Or do you have another suggestion? Thanks again, Fred At 10:08 AM 5/11/2004, you wrote: Hi, Is there a way, within a single context, to separate out the static content to some other file system location. Of course, there are many ways, none of them advised. You want to keep your webapp as a whole, that's the whole point of a WAR file. You can symlink (at the filesystem level) or use normal HTTP linking to access your static content. But you can't symlink in a WAR, so... I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. And I agree with Justin, just to be clear. I wasn't advocating anything different from what he said, just showing you that it can technically be done. If crossContext forwards are the worst design choices on this list, we'll be in great shape. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: forwarding across contexts?
Fred, Thanks for the additional info about your app ... it makes it much easier to talk about these things. :) There are many (valid) ways to proceed, many of which vary in the amount of standards they adhere to (how much you want to align yourself with Tomcat). I'll just give you my thoughts. At 09:02 AM 5/11/2004, you wrote: Let me describe a bit about our application, just in case you (or anyone else) have some specific advice. My client is a publisher, and the bulk of the site will be many thousands of published articles and associated content such as figure, tables, etc. The HTML content, however, will be served by tomcat, since it has some dynamic components. The biggest question, then, has to do with your security requirements. Specifically, does this content need to be protected or can it just sit out there for anyone to grab? If it need not be protected, this is, IMHO, a textbook example of when to use Apache. You've got a large collection of static data and a relatively small web application associated with it. You've probably got different groups working on the different parts (the publisher's content and the HTML pages), so it makes sense to separate it out and serve the static content by generating links to your static web server's content from your dynamic HTML. Additionally, you could then put the two pieces on separate machines (one or more with Apache, one or more with Tomcat) to keep them separated even more cleanly. If the content needs to be protected, I would create a separate directory and put the content there. Symlink this to the base of your Tomcat webApp and let Tomcat serve it normally, employing whatever security scheme you're using. You won't be able to deploy the entire thing as a single WAR, but it doesn't sound like you really care to do this anyways. This is why it's not practical to bundle everything into a war file. Instead, I need tomcat to point to the file system where many users will be building the site. On the other hand, the war file can easily contain the java infrastructure (struts, velocity, configuration information, etc.). I'd like to be able to keep the small war file, hot deploy, etc., but have the raw content (static and otherwise) live elsewhere. Given that, would you solve it with multiple contexts? Or do you have another suggestion? Alternately, you could extend the DefaultServlet (if you don't mind tying yourself to Tomcat and your version) with your own custom static content servlet that gets data from an arbitrary directory. If you can't be tied to Tomcat, use the source as a base to write your own default servlet. This solution is more on the slick side of things, so it wouldn't be preferable ... better to stay within the mainstream boundaries. If you can, look into symlinking or Apache. Consider the extend/impl DefaultServlet idea. If you're still not satisfied, having two separate contexts can be made to work. Perhaps others have additional ideas. Fred Good luck, justin At 10:08 AM 5/11/2004, you wrote: Hi, Is there a way, within a single context, to separate out the static content to some other file system location. Of course, there are many ways, none of them advised. You want to keep your webapp as a whole, that's the whole point of a WAR file. You can symlink (at the filesystem level) or use normal HTTP linking to access your static content. But you can't symlink in a WAR, so... I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. And I agree with Justin, just to be clear. I wasn't advocating anything different from what he said, just showing you that it can technically be done. If crossContext forwards are the worst design choices on this list, we'll be in great shape. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] __ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php __ - To unsubscribe,
RE: forwarding across contexts?
Justin, Thanks again for taking the time to think about this with me. Alas, my customer's deployment platform is windows. So no symlinks. No Apache (they use IIS). Complicated security model for everything on the site except for decorative gifs. So Tomcat does it all! Thanks, Fred At 03:13 PM 5/11/2004, you wrote: Fred, Thanks for the additional info about your app ... it makes it much easier to talk about these things. :) There are many (valid) ways to proceed, many of which vary in the amount of standards they adhere to (how much you want to align yourself with Tomcat). I'll just give you my thoughts. At 09:02 AM 5/11/2004, you wrote: Let me describe a bit about our application, just in case you (or anyone else) have some specific advice. My client is a publisher, and the bulk of the site will be many thousands of published articles and associated content such as figure, tables, etc. The HTML content, however, will be served by tomcat, since it has some dynamic components. The biggest question, then, has to do with your security requirements. Specifically, does this content need to be protected or can it just sit out there for anyone to grab? If it need not be protected, this is, IMHO, a textbook example of when to use Apache. You've got a large collection of static data and a relatively small web application associated with it. You've probably got different groups working on the different parts (the publisher's content and the HTML pages), so it makes sense to separate it out and serve the static content by generating links to your static web server's content from your dynamic HTML. Additionally, you could then put the two pieces on separate machines (one or more with Apache, one or more with Tomcat) to keep them separated even more cleanly. If the content needs to be protected, I would create a separate directory and put the content there. Symlink this to the base of your Tomcat webApp and let Tomcat serve it normally, employing whatever security scheme you're using. You won't be able to deploy the entire thing as a single WAR, but it doesn't sound like you really care to do this anyways. This is why it's not practical to bundle everything into a war file. Instead, I need tomcat to point to the file system where many users will be building the site. On the other hand, the war file can easily contain the java infrastructure (struts, velocity, configuration information, etc.). I'd like to be able to keep the small war file, hot deploy, etc., but have the raw content (static and otherwise) live elsewhere. Given that, would you solve it with multiple contexts? Or do you have another suggestion? Alternately, you could extend the DefaultServlet (if you don't mind tying yourself to Tomcat and your version) with your own custom static content servlet that gets data from an arbitrary directory. If you can't be tied to Tomcat, use the source as a base to write your own default servlet. This solution is more on the slick side of things, so it wouldn't be preferable ... better to stay within the mainstream boundaries. If you can, look into symlinking or Apache. Consider the extend/impl DefaultServlet idea. If you're still not satisfied, having two separate contexts can be made to work. Perhaps others have additional ideas. Fred Good luck, justin At 10:08 AM 5/11/2004, you wrote: Hi, Is there a way, within a single context, to separate out the static content to some other file system location. Of course, there are many ways, none of them advised. You want to keep your webapp as a whole, that's the whole point of a WAR file. You can symlink (at the filesystem level) or use normal HTTP linking to access your static content. But you can't symlink in a WAR, so... I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. And I agree with Justin, just to be clear. I wasn't advocating anything different from what he said, just showing you that it can technically be done. If crossContext forwards are the worst design choices on this list, we'll be in great shape. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: forwarding across contexts?
At 01:04 PM 5/11/2004, you wrote: Justin, Thanks again for taking the time to think about this with me. Alas, my customer's deployment platform is windows. So no symlinks. No Apache (they use IIS). Complicated security model for everything on the site except for decorative gifs. So Tomcat does it all! In that case, I would personally either extend or implement the DefaultServlet to read resources from a designated local location (given by a servlet init param). It seems silly to add a webApp that consists only of static content in this case ... but you know how to do it if you deem that best. Once you decide what you're going to do and implement it, I'd be curious to get your feedback and/or comments on your method. If you remember this conversation when you're done, shoot me/us an email with any observations. Good luck, justin At 03:13 PM 5/11/2004, you wrote: Fred, Thanks for the additional info about your app ... it makes it much easier to talk about these things. :) There are many (valid) ways to proceed, many of which vary in the amount of standards they adhere to (how much you want to align yourself with Tomcat). I'll just give you my thoughts. At 09:02 AM 5/11/2004, you wrote: Let me describe a bit about our application, just in case you (or anyone else) have some specific advice. My client is a publisher, and the bulk of the site will be many thousands of published articles and associated content such as figure, tables, etc. The HTML content, however, will be served by tomcat, since it has some dynamic components. The biggest question, then, has to do with your security requirements. Specifically, does this content need to be protected or can it just sit out there for anyone to grab? If it need not be protected, this is, IMHO, a textbook example of when to use Apache. You've got a large collection of static data and a relatively small web application associated with it. You've probably got different groups working on the different parts (the publisher's content and the HTML pages), so it makes sense to separate it out and serve the static content by generating links to your static web server's content from your dynamic HTML. Additionally, you could then put the two pieces on separate machines (one or more with Apache, one or more with Tomcat) to keep them separated even more cleanly. If the content needs to be protected, I would create a separate directory and put the content there. Symlink this to the base of your Tomcat webApp and let Tomcat serve it normally, employing whatever security scheme you're using. You won't be able to deploy the entire thing as a single WAR, but it doesn't sound like you really care to do this anyways. This is why it's not practical to bundle everything into a war file. Instead, I need tomcat to point to the file system where many users will be building the site. On the other hand, the war file can easily contain the java infrastructure (struts, velocity, configuration information, etc.). I'd like to be able to keep the small war file, hot deploy, etc., but have the raw content (static and otherwise) live elsewhere. Given that, would you solve it with multiple contexts? Or do you have another suggestion? Alternately, you could extend the DefaultServlet (if you don't mind tying yourself to Tomcat and your version) with your own custom static content servlet that gets data from an arbitrary directory. If you can't be tied to Tomcat, use the source as a base to write your own default servlet. This solution is more on the slick side of things, so it wouldn't be preferable ... better to stay within the mainstream boundaries. If you can, look into symlinking or Apache. Consider the extend/impl DefaultServlet idea. If you're still not satisfied, having two separate contexts can be made to work. Perhaps others have additional ideas. Fred Good luck, justin At 10:08 AM 5/11/2004, you wrote: Hi, Is there a way, within a single context, to separate out the static content to some other file system location. Of course, there are many ways, none of them advised. You want to keep your webapp as a whole, that's the whole point of a WAR file. You can symlink (at the filesystem level) or use normal HTTP linking to access your static content. But you can't symlink in a WAR, so... I believe that Yoav's suggestion is that I set up the empty path () context for this purpose. However, this is where I started, and Justin argued against this cross-context approach. And I agree with Justin, just to be clear. I wasn't advocating anything different from what he said, just showing you that it can technically be done. If crossContext forwards are the worst design choices on this list, we'll be in great shape. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and
forwarding across contexts?
Hi, I'm trying to install a filter into the default context that forwards to my application (in another context) and it doesn't seem to want to work. (jboss 3.2.3 with embedded tomcat 4.1.29) In researching this, I've seen various hints that this may in fact be illegal. Can anyone confirm? The REASON I want to do this is that I want to be able to take advantage of simple URLS with the default context, as in /images/whatever.gif, and have them be served by DefaultServlet, which conveniently knows how to handle all that sort of stuff, set mime types, etc. I'm also hoping that DefaultServlet was written by someone more clever than me! But, I also want to capture certain simple URLs and forward these to another context. As in /protected.html needs to be forwarded to /accesscheck/protected.html or similar. Am I on the wrong track here? Is it possible to forward (via RequestDispatcher) from one context to another? If not, how can I take advantage of DefaultServlet in my application? Many thanks, Fred Toth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forwarding across contexts?
At 07:04 PM 5/10/2004, you wrote: Hi, I'm trying to install a filter into the default context that forwards to my application (in another context) and it doesn't seem to want to work. (jboss 3.2.3 with embedded tomcat 4.1.29) In researching this, I've seen various hints that this may in fact be illegal. Can anyone confirm? It is generally good design practice to limit interactions between your webapps except for strongly defined specific interfaces that promote modularity. Doing something like you're suggesting will likely lead to messy, difficult code to work with ... not because it's a necessarily bad design idea, but rather because the premise behind J2EE is that code bases are designed, coded, deployed, and maintained as independent applications. They're not meant to ineroperate in a fluid way. It's possible to do what you're suggesting, but not recommended. The REASON I want to do this is that I want to be able to take advantage of simple URLS with the default context, as in /images/whatever.gif, and have them be served by DefaultServlet, which conveniently knows how to handle all that sort of stuff, set mime types, etc. I'm also hoping that DefaultServlet was written by someone more clever than me! Resources need not be within the ROOT web application to be served by the DefaultServlet. You'll notice that the DefaultServlet is defined within the global web.xml (I haven't worked with recent versions of jBoss, so I'm not sure exactly where they put this these days), which means that all applications inherit it. This means that resources like /images/whatever.gif and /mywebapp/images/whatever.gif will both be served by the DefaultServlet unless you configure it otherwise. But, I also want to capture certain simple URLs and forward these to another context. As in /protected.html needs to be forwarded to /accesscheck/protected.html or similar. Am I on the wrong track here? Is it possible to forward (via RequestDispatcher) from one context to another? If not, how can I take advantage of DefaultServlet in my application? See ServletContext#getContext(String). Again, I predict you'll find this to be a clunky and frustrating way to do things. Unless you have an over-riding reason to do otherwise, embrace the idea of separate and distinct web applications and let the container do this URL parsing and forwarding for you. Many thanks, Fred Toth Good luck, justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forwarding across contexts?
Justin, Thanks very much for your considered reply. You both solved my problem and made me question my approach at the same time. In re-thinking this in terms of separated webapps, I've hit another issue. If I solve this problem within one particular web application, I have to be able to point this webapp to another place in the file system (other than $CATALINA_HOME/webapp). I had figured out how to do that with the ROOT application, but I'm not sure how to do this within a war file. In short, how does one deploy a war file such that it looks for content (/images/whatever.gif) in a configurable location in the file system? If I can figure that out, I think I can abandon the cross-context issue for good! Thanks, Fred At 10:23 PM 5/10/2004, you wrote: At 07:04 PM 5/10/2004, you wrote: Hi, I'm trying to install a filter into the default context that forwards to my application (in another context) and it doesn't seem to want to work. (jboss 3.2.3 with embedded tomcat 4.1.29) In researching this, I've seen various hints that this may in fact be illegal. Can anyone confirm? It is generally good design practice to limit interactions between your webapps except for strongly defined specific interfaces that promote modularity. Doing something like you're suggesting will likely lead to messy, difficult code to work with ... not because it's a necessarily bad design idea, but rather because the premise behind J2EE is that code bases are designed, coded, deployed, and maintained as independent applications. They're not meant to ineroperate in a fluid way. It's possible to do what you're suggesting, but not recommended. The REASON I want to do this is that I want to be able to take advantage of simple URLS with the default context, as in /images/whatever.gif, and have them be served by DefaultServlet, which conveniently knows how to handle all that sort of stuff, set mime types, etc. I'm also hoping that DefaultServlet was written by someone more clever than me! Resources need not be within the ROOT web application to be served by the DefaultServlet. You'll notice that the DefaultServlet is defined within the global web.xml (I haven't worked with recent versions of jBoss, so I'm not sure exactly where they put this these days), which means that all applications inherit it. This means that resources like /images/whatever.gif and /mywebapp/images/whatever.gif will both be served by the DefaultServlet unless you configure it otherwise. But, I also want to capture certain simple URLs and forward these to another context. As in /protected.html needs to be forwarded to /accesscheck/protected.html or similar. Am I on the wrong track here? Is it possible to forward (via RequestDispatcher) from one context to another? If not, how can I take advantage of DefaultServlet in my application? See ServletContext#getContext(String). Again, I predict you'll find this to be a clunky and frustrating way to do things. Unless you have an over-riding reason to do otherwise, embrace the idea of separate and distinct web applications and let the container do this URL parsing and forwarding for you. Many thanks, Fred Toth Good luck, justin - 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]
