tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: <resource-ref> in web.xml
Date Wed, 24 Apr 2013 20:27:58 GMT
Hash: SHA256


On 4/24/13 2:22 PM, Jeffrey Janner wrote:
>> -----Original Message----- From: Jeffrey Janner
>> [] Sent: Wednesday, April 24,
>> 2013 1:12 PM To: Tomcat Users List Subject: RE: <resource-ref> in
>> web.xml
>>> -----Original Message----- From: Christopher Schultz
>>> [] Sent: Wednesday, April
>>> 24, 2013 12:28 PM To: Tomcat Users List Subject: Re:
>>> <resource-ref> in web.xml
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> Jeff,
>>> On 4/23/13 11:40 AM, Jeffrey Janner wrote:
>>>>> -----Original Message----- From: Christopher Schultz 
>>>>> [] Sent: Thursday, April
>>>>> 18, 2013 5:01 PM To: Tomcat Users List Subject: Re:
>>>>> <resource-ref> in web.xml
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>> Jakub,
>>>>> On 4/17/13 9:22 PM, Jakub 1983 wrote:
>>>>>> can I define database connection only in web.xml, without
>>>>>> using context.xml files ?
>>>>>> can I pass database url, login and password into
>>>>>> <resource-ref> ?
>>>>>> when I define database conn in context.xml, resource-ref
>>>>>> is not
>>>>> needed
>>>>>> at all, so what is it actually for ?
>>>>> If you define your database configuration in server.xml,
>>>>> you'll have to map from global to local scope. You don't
>>>>> need to do this with context.xml because the scope is -- by
>>>>> definition -- already
>> local.
>>>>> - -chris
>>>> Chris - Am I reading that correctly?  If in my context.xml
>>>> file, I define a DB resource as: <Resource
>>>> name="jdbc/oracleUCPPool" 
>>>> type="oracle.ucp.jdbc.PoolDataSource" 
>>>> factory="oracle.ucp.jdbc.PoolDataSourceImpl"
>>>> auth="Container" 
>>>> connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource"
>>>> ... obviously redacted stuff ... /> I DO NOT need to add
>>>> these lines to
>>> my
>>>> web.xml? <resource-ref> <description>Oracle Universal
>>>> Connection Pool</description>
>>>> <res-ref-name>jdbc/oracleUCPPool</res-ref-name> 
>>>> <res-type>javax.sql.DataSource</res-type> 
>>>> <res-auth>Container</res-auth> </resource-ref>
>>> I believe this is correct. It should be easy to try :)
>>>> That also brings up another, related, question. In my old
>>>> web.xml,
>> I
>>>> had this entry: <context-param>
>>>> <param-name>LOG4J_PROPS</param-
>> name>
>>>> <param-value>/WEB-INF/</param-value> 
>>>> </context-param> Which I removed and replaced with an entry
>>>> in the context.xml file: <Parameter name="LOG4J_PROPS" 
>>>> value="/WEB-INF/" override="false" />
>>>> However, that didn't work. I had to provide the full path to
>>>> the file in the
>> value
>>>> parameter. Is there a particular reason why?
>>> The two above are documented to be equivalent, assuming no
>>> other factors are at work (e.g. Tomcat wasn't reading your new
>>> META- INF/context.xml file because there was one already in 
>>> conf/[Engine]/[Host]/[app].xml.
>>> If it's not working, start a new thread to make sure you
>>> understand how it's all supposed to work and possibly follow-up
>>> with a bug
>> report.
>>>> Or would it be something inside our code?
>>> Tomcat doesn't use that value for anything, so it must be your
>>> code reading it and interpreting it (hopefully using 
>>> ServletContext.getResource()).
>>> - -chris
>> Actually, there is no META-INF file, we maintain the context.xml 
>> manually, since we multi-tenant and don't want to build
>> tenant-specific wars.  So it was definitely reading the latest
>> version. Code uses context.getInitParameter("LOG4J_PROPS") which
>> is passed directly to the log4j init routine (I think, still
>> checking one reference).
> Yes, the returned string is passed unmolested to log4j's
> PropertyConfigurator.
>> The error was being reported in the catalina logs and
>> specifically mentioned the string in the error message.  Simply
>> switching to the FQPath did the trick.

I wouldn't expect Tomcat to modify the value you were passing. Are you
*sure* it was working in web.xml before you moved it into context.xml?

Using the fully-qualified path should pretty much always work, but if
you know that the log4j configuration will be bundled as part of the
web application, then you may as well make it context-relative. You
should also use ServletContext.getResource and not read directly from
the filesystem for a number of reasons.

>> Of course, part of the reason for the change is that we'll be
>> moving the file out of the WEB-INF directory in the future. Part
>> of that multi-tenancy thing, so I'll be using FQPs in the future
>> anyway.  It was just a curiosity that expected behavior did not
>> occur.

Hmm. So, you'll be storing both context.xml *and*
outside of the webapp? Sounds like your deployments are going to
become more and more complex. Are you hosting your own webapp(s) on
your own servers? Or are you hosting clients' (potentially customized)
webapps on your servers? If you have full control, I'd put everything
possible into the webapp just for convenience.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message