tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ruthenbeck <just...@nextengine.com>
Subject RE: forwarding across contexts?
Date Tue, 11 May 2004 20:20:16 GMT
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 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: tomcat-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>______________________________________________
>>Justin Ruthenbeck
>>Software Engineer, NextEngine Inc.
>>justinr - AT - nextengine DOT com
>>Confidential. See:
>>http://www.nextengine.com/confidentiality.php
>>______________________________________________
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


______________________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php
______________________________________________


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message