On Mon, 8 Jul 2002, dbt1 wrote:

> Date: Mon, 8 Jul 2002 10:31:31 -0600
> From: dbt1 <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>,
>      Struts Users Mailing List <[EMAIL PROTECTED]>,
>      [EMAIL PROTECTED]
> Subject: Tomcat 4 cross ServletContext attributes and standalone server
>
> I curently have 2 issues and hope someone may quickly point me to the right
> solutions.
> Environment: Tomcat 4.03, Struts 1.1
>
> Issue 1: Tomcat standalone to serve other file types such as .pdf .ppt .doc
> Previously I use Apache as a web server connected to Tomcat 3.3 for jsp
> pages. URLs to the above file types work fine. Changing to Tomcat 4
> standalone, everything is great with jsp, but Tomcat web server does not
> recognize and serve the other file types. I expect appropriate setting of
> file types would sold this problem so Tomcat Standalone will be appropriate
> for mostly dynamic jsp site without using Apache and connectors.
>

What does "does not recognize and serve the other file types" mean?  If
it's just an issue of getting the correct content type set, you can
configure that for yourself by using <mime-type> entries in web.xml --
either for your app itself, or for the entire Tomcat installation (edit
the file "$CATALINA_HOME/conf/web.xml" for those).  If you are getting 404
errors, that means you don't have the files in the right place, or
something else is wrong.

> Issue 2: Using ServletContext attributes as global variables accross web
> applications within the same virtual host and across different virtual
> hosts. My arrangement is as follows:
>
>     VirtualHost1/ROOT/mainApp
>                        /sub1/subApp1
>     VirtualHost2/ etc.
>
> ServletContext attributes set in subApp1 are alive and available to subApp1.
> >From mainApp, I need to get attributes in subApp1. From mainApp, I access
> Struts 1.1 ActionServlet and get to its ServletContext
> (getServlet().getServletContext()). From mainApp ServletContext, I get to
> subApp1 ServletContext with getContext("/subApp1") and to get the required
> attributes of subApp1, which I know they are there and not null as tested
> from subApp1 ServletContext. The whole code  is:
>
> (MyPlugIn) myPlugIn = (MyPlugIn)
> ((getServlet().getServletContext()).getContext("/subApp1")).getAttribute(myP
> lugIn);
>
> This line of code gives null value from both mainApp and subApp1
> ServletContext. I did explicitly set appropriate docBase and
> crossContext="true" for both mainApp and subApp1 in tomcat4 server.xml
>

This sounds like an issue that should be reported against Tomcat.

> The question are:
>     1) How do I get global variables across web applications within 1
> virtual host and across virtual hosts using Tomcat 4 container?
>     2) Is there a better method for sharing global variables across web
> applications within the same virtual host, and across virtual hosts in the
> same server?

One option is to put the relevant classes in Tomcat's common/lib
directory, and make the appropriate information available through some
static method (such as a factory pattern).  Such statics are shared across
all virtual hosts and all webapps in a single Tomcat instance.

>     3) What is the best approach to scale from the above scenario to
> distributed environment?

Store the shared stuff in a database, EJB, LDAP server, or some other
external resource.

>     4) If Ldap is used for global variable distributed environment, what is
> the best design for mostly read and few updates of JavaBeans to Ldap, both
> for performance and security.
>

Most LDAP servers are optimized for read performance already.  If that's
not fast enough, consider caching the retrieved information in servlet
context attributes in each webapp -- keeping in mind that you will need
some technique to ensure that updates get propogated in a timely manner.

> Any help is greatly appreciated. Thanks.
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to