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 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, 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, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
