Erik, here goes my context.xml, Tomcat renames it the same as the app's
directory. I assume your Tomcat has autodeploy enabled.
<!--By Ivan: WAR-contained Application Context-->
<!--Path defines the directory name created when war is deployed-->
<Context path="/nahrgisdev" docBase="nahrgisdev" debug="5"
reloadable="true" crossContext="true">
<!--Development-->
<Resource name="jdbc/orcl" auth="Container"
type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/orcl">
<parameter>
<name>factory</name>
<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<!--By Ivan: Parameters for RAC connection load balancing-->
<parameter>
<name>url</name>
<value>jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCO
L=TCP)(HOST=node1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=node2)(PORT=1
521))(CONNECT_DATA=(SERVICE_NAME=orcl)))</value>
</parameter>
<parameter>
<name>username</name>
<value>*****</value>
</parameter>
<parameter>
<name>password</name>
<value>*****</value>
</parameter>
<parameter>
<name>maxActive</name>
<value>10</value>
</parameter>
<parameter>
<name>maxIdle</name>
<value>10</value>
</parameter>
<parameter>
<name>maxWait</name>
<value>-1</value>
</parameter>
<parameter>
<name>removeAbandoned</name>
<value>true</value>
</parameter>
<parameter>
<name>removeAbandonedTimeout</name>
<value>60</value>
</parameter>
<parameter>
<name>logAbandoned</name>
<value>true</value>
</parameter>
</ResourceParams>
</Context>
-----Original Message-----
From: Erik Weber [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 31, 2004 4:30 PM
To: Struts Users Mailing List
Subject: Re: Classloading problem
I have tried this repeatedly. I am using the same Foo.xml file that does
work when placed in conf/Catalina/localhost/. I have tried with and
without the path and docBase attributes to the Context element. I have
renamed the file to context.xml and it is in META-INF in my war file. I
have also tried putting Foo.xml or context.xml within a
META-INF/context.xml/ *directory* as the documentation suggests.
DBCP throws an Exception on startup that it cannot create a JDBC driver
of class '' for connect URL 'null'. I am supposing that the context file
is never loaded. Also Tomcat creates a Foo.xml directory inside of
conf/Catalina/localhost with nothing in it. If I try restarting the
server, I also get a FileNotFoundException on Foo.xml, saying it "is a
directory" (good grief). I have tried hot deploy and deploying via the
manager web app as well.
I basically observed the same behavior that Ivan described.
I would love to see that example if you can find it.
Erik
Kris Schneider wrote:
>Hang on, my bad - it should be /META-INF/context.xml. So, rename
Foo.xml to be
>context.xml and place it in *META-INF*.
>
>Quoting Erik Weber <[EMAIL PROTECTED]>:
>
>
>
>>Kris, this is from context.html in the Tomcat 5 docs:*
>>
>>Please note that for tomcat 5.x, unlike tomcat 4.x, it is NOT
>>recommended to place <Context> elements directly in the server.xml
>>file.* Instead, put them in the META-INF/context.xml directory of your
>>WAR file or the conf directory as described above.
>>
>>So here I am, stupidly trying to put my Foo.xml file within
>>/META-INF/context.xml/ (and various variations of that) of my web app.
>>
>>So should I rename Foo.xml to context.xml (I ask because in the conf
>>directory I have been naming it Foo.xml, not context.xml), and put it
in
>>*WEB-INF*?
>>
>>Could you show me where you found how to do this in the docs? Am I
just
>>completely misreading the above sentence?
>>
>>Thanks for your help,
>>Erik
>>
>>
>>Kris Schneider wrote:
>>
>>
>>
>>>Can you provide some more detail on the problems you're running into
with
>>>
>>>
>>using
>>
>>
>>>WEB-INF? I've got a simple one lying around here somewhere...
>>>
>>>WEB-INF/context.xml:
>>>--------------------
>>><Context path="/init">
>>> <Loader delegate="false"/>
>>> <Manager pathname=""/>
>>></Context>
>>>
>>>Seems to work fine with TC 5...
>>>
>>>Quoting Erik Weber <[EMAIL PROTECTED]>:
>>>
>>>
>>>
>>>
>>>
>>>>Also, since you appear to be trying to follow the documenation, have
you
>>>>ever gotten a Context XML file placed within the META-INF directory
of
>>>>your web app to work? I can't get this to work (I have gotten them
to
>>>>work when placed in the conf directory -- though I had to learn the
hard
>>>>way to take write permissions away from Tomcat after it very rudely
>>>>deleted one). The documentation is confusing, and the example web
app
>>>>mysteriously does not include a Context XML file at all, despite
that
>>>>pretty much any serious web app is going to need one (unless you
declare
>>>>everything in server.xml).
>>>>
>>>>If you have an example of this working, please share it with me.
>>>>
>>>>Erik
>>>>
>>>>
>>>>Ivan Vasquez wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Sure, in common/lib it works well. But from Tomcat docs:
>>>>>http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.
html
>>>>>
>>>>>The following rules cover about 95% of the decisions that
application
>>>>>developers and deployers must make about where to place class and
>>>>>resource files to make them available to web applications:
>>>>>
>>>>> * For classes and resources specific to a particular web
>>>>>application, place unpacked classes and resources under
/WEB-INF/classes
>>>>>of your web application archive, or place JAR files containing
those
>>>>>classes and resources under /WEB-INF/lib of your web application
>>>>>archive.
>>>>> * For classes and resources that must be shared across all
web
>>>>>applications, place unpacked classes and resources under
>>>>>$CATALINA_BASE/shared/classes, or place JAR files containing those
>>>>>classes and resources under $CATALINA_BASE/shared/lib.
>>>>>
>>>>>--Then goes on...---
>>>>>
>>>>>Common - This class loader contains additional classes that are
made
>>>>>visible to both Tomcat internal classes and to all web
applications.
>>>>>Normally, application classes should NOT be placed here. All
unpacked
>>>>>classes and resources in $CATALINA_HOME/common/classes, as well as
>>>>>classes and resources in JAR files under the
>>>>>$CATALINA_HOME/commons/endorsed and $CATALINA_HOME/common/lib
>>>>>directories, are made visible through this class loader.
>>>>>
>>>>>Shared - This class loader is the place to put classes and
resources
>>>>>that you wish to share across ALL web applications (unless Tomcat
>>>>>internal classes also need access, in which case you should put
them in
>>>>>the Common class loader instead). All unpacked classes and
resources in
>>>>>$CATALINA_BASE/shared/classes, as well as classes and resources in
JAR
>>>>>files under $CATALINA_BASE/shared/lib, are made visible through
this
>>>>>class loader.
>>>>>
>>>>>----
>>>>>
>>>>>In our case we want to share jars common to all applications, but
none
>>>>>of them are required by Tomcat.
>>>>>
>>>>>Ivan.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Erik Weber [mailto:[EMAIL PROTECTED]
>>>>>Sent: Tuesday, August 31, 2004 12:52 PM
>>>>>To: Struts Users Mailing List
>>>>>Subject: Re: Classloading problem
>>>>>
>>>>>I have been using 5.0.27, putting my JDBC drivers in common/lib,
and my
>>>>>struts jars in WEB-INF/lib of each application, and haven't had any
>>>>>problems. Why do you say "incorrectly"?
>>>>>
>>>>>Erik
>>>>>
>>>>>
>>>>>Ivan Vasquez wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>We have Tomcat 5.0.16 and were incorrectly placing common jars
(such as
>>>>>>JDBC drivers) in /common/lib.
>>>>>>
>>>>>>Now we just moved them to /shared/lib (for truly common stuff) and
>>>>>>WEB-INF/lib, but now all applications complain giving a
>>>>>>java.lang.ClassNotFoundException, just like if things weren't in
>>>>>>Tomcat's classpath anymore. Apps and Tomcat restarts have been
done
>>>>>>several times.
>>>>>>
>>>>>>Is there anything in web.xml, server.xml, etc that needs to be
set?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>What
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>are we possibly missing? Tomcat docs are pretty straightforward
about
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>and everything seems right.
>>>>>>
>>>>>>Once again, thanks in advance.
>>>>>>Ivan.
>>>>>>
>>>>>>
>
>
>
---------------------------------------------------------------------
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]
