> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, April 24, 2013 3:28 PM > To: Tomcat Users List > Subject: Re: <resource-ref> in web.xml > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jeff, > > On 4/24/13 2:22 PM, Jeffrey Janner wrote: > >> -----Original Message----- From: Jeffrey Janner > >> [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, April 24, > >> 2013 1:12 PM To: Tomcat Users List Subject: RE: <resource-ref> in > >> web.xml > >> > >>> -----Original Message----- From: Christopher Schultz > >>> [mailto:ch...@christopherschultz.net] 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 > >>>>> [mailto:ch...@christopherschultz.net] 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/Log4j.properties</param-value> > >>>> </context-param> Which I removed and replaced with an entry in the > >>>> context.xml file: <Parameter name="LOG4J_PROPS" > >>>> value="/WEB-INF/Log4j.properties" 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? >
For the last 8 years or so. > 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* log4j.properties > 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 Main thing to understand is we are multi-tenant with >50 tenants split between a number of servers. But the product must also be deployable on customer hardware via an install script of some sort. So we're trying to limit the moving parts, so to speak. The product consists of two web-apps and two related, but standalone applications, mainly load offloading. Current deployment is into a common directory structure that contains a common log directory for all the apps with the web-apps in an expanded format. Goal is to move the web-apps into war files that we can just drop into Tomcat, but keep the configuration info, log4j & db connections, either in the current directory structure, or in the context.xml. Note, I really don't want to have to create 50+ individual war files every 2 weeks, not to mention I have no knowledge of field deployment details such as DB usernames and passwords. Figure, once set up for a customer, I'd probably never have to touch the context.xml and log4j.properties files ever again, and can then just do the bi-weekly upgrades as war drops. It's really a lot less complicated than it sounds.
