You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Holly <mh...@talisentech.com> on 2003/06/12 20:33:45 UTC

A question of configuration

I am trying to config a Tomcat 4.1.18 server.

I want to be able to use Tomcat manger from my ANT build to install
the war file and run tests on it(junitee).

My problem is that my app has two jdbc Data sources defined by
jndi naming in the server.xml file.  Right now these data sources
are defined in a specific <context> element for my application.

I am wanting to move these data dources out of this context so that I
can get rid of the context and let Tomcat create it when the app is
deployed.

The best I can tell is that I have 3 possible options:

1. I could put the <resource> blocks under the <GlobalNamingResources> tag.
  PRO: This would make my data sources available to all apps on this server
  CON: This would make my data sources available to all apps on this server
;~)

2. I could put the <resource> blocks under the <DefaultContext> tag. It
looks
   like apps that are deployed in this manner inherit the properties of the
default
   context.
  PRO: This would make my data sources available to all apps on this server
  CON: This would make my data sources available to all apps on this server
;~)

3. I could put the <resource> blocks in the web.xml file (I think).
  PRO: This would make my data sources available to just this application
  CON: This would make my data sources available to just this application
;~)

I am running one Tomcat instance to serve out 2-3 applications whose
resources may not neccesarily overlap.

I have browsed through the server configuration document and the 2.3 servlet
spec
on deployment descriptors, but they have not been a big help.

If I had my choice I would pick #3 so my dataSources remain specific to the
application.

Could someone discuss the differences between #1, #2, and #3?  If you have
an example of
#3 that would be incredibly helpful.

I guess I'm just looking for some advice on what would be best to do here.
As always the solution
has to be fast, flexible, and free ;~) (Well at least two of those)...(Well
maybe one...)

Thanks

Michael


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


Re: A question of configuration

Posted by Liem Do <li...@waterware.com>.
Hi,

You could have a myapp.xml file that defines the context for your
application and include the necessary resource definitions in it. Then you
can take out your application's <context> element from server.xml and tomcat
will create the context from this file. This file is placed in the webapps
directory and will look something like this:

<Context path="/myapp" ...>
    <Resource name="jdbc/mydb" auth="Container"
              type="javax.sql.DataSource"
       description="User database for postconf">
    </Resource>
    <ResourceParams name="jdbc/mydb">
      <parameter>
        <name>user</name>
        <value>myuser</value>
      </parameter>
      ... any other parameters here
    </ResourceParams>
</Context>

This should solve #3 for your case. This is how the manager and admin apps
are done. Take a look at $TOMCAT_HOME/webapps/manager.xml file for an
example. I think you can also place this file in the META-INF directory of
your war file as well but I haven't tried that.

HTH,
LD

----- Original Message ----- 
From: "Michael Holly" <mh...@talisentech.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, June 12, 2003 11:33 AM
Subject: A question of configuration


> I am trying to config a Tomcat 4.1.18 server.
>
> I want to be able to use Tomcat manger from my ANT build to install
> the war file and run tests on it(junitee).
>
> My problem is that my app has two jdbc Data sources defined by
> jndi naming in the server.xml file.  Right now these data sources
> are defined in a specific <context> element for my application.
>
> I am wanting to move these data dources out of this context so that I
> can get rid of the context and let Tomcat create it when the app is
> deployed.
>
> The best I can tell is that I have 3 possible options:
>
> 1. I could put the <resource> blocks under the <GlobalNamingResources>
tag.
>   PRO: This would make my data sources available to all apps on this
server
>   CON: This would make my data sources available to all apps on this
server
> ;~)
>
> 2. I could put the <resource> blocks under the <DefaultContext> tag. It
> looks
>    like apps that are deployed in this manner inherit the properties of
the
> default
>    context.
>   PRO: This would make my data sources available to all apps on this
server
>   CON: This would make my data sources available to all apps on this
server
> ;~)
>
> 3. I could put the <resource> blocks in the web.xml file (I think).
>   PRO: This would make my data sources available to just this application
>   CON: This would make my data sources available to just this application
> ;~)
>
> I am running one Tomcat instance to serve out 2-3 applications whose
> resources may not neccesarily overlap.
>
> I have browsed through the server configuration document and the 2.3
servlet
> spec
> on deployment descriptors, but they have not been a big help.
>
> If I had my choice I would pick #3 so my dataSources remain specific to
the
> application.
>
> Could someone discuss the differences between #1, #2, and #3?  If you have
> an example of
> #3 that would be incredibly helpful.
>
> I guess I'm just looking for some advice on what would be best to do here.
> As always the solution
> has to be fast, flexible, and free ;~) (Well at least two of
those)...(Well
> maybe one...)
>
> Thanks
>
> Michael
>
>
> ---------------------------------------------------------------------
> 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