Mark Eggers wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote:
Hello
We have a setup which compiles WAR applications once and deploys
them in various environments. Each environment has its own per
application Log4j configuration (WARN for production, DEBUG for
development etc.) which should survive application redeployment.
So far the solution is:
webapps/myapp/WEB-INF/web.xml
... <context-param> <param-name>log4jConfigLocation</param-name>
<param-value>file:///opt/tomcat6/conf/myapp/log4j.xml</param-value>
</context-param>
...
Pretty standard, works.
Question is, how can I make sure the Log4j configuration path is
not hard coded in the 'web.xml' at development time. Idea was:
webapps/myapp/META-INF/context.xml ... <Parameter
name="log4jConfigLocation" value="file://TBD" /> ...
and change it after the application deployment:
conf/Catalina/localhost/myapp.xml ... <Parameter
name="log4jConfigLocation"
value="file:///opt/tomcat6/conf/myapp/log4j.xml" /> ...
Tomcat simply ignores both of these context XML files, or at least
the parameters defined in them. I read through all mailing lists,
all documentations, switched on debug to the 'finest' level, still
no avail. How difficult can this be?
Details:
Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011
11:20:06 Server number: 6.0.35.0 OS Name: Linux OS
Version: 2.6.18-348.el5 Architecture: amd64 JVM Version:
1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc.
Cheers B.
I'm just noodling - haven't tried this. Your mileage may vary, void
where prohibited, etc., etc., etc.
How about:
1. use Parameter in context.xml to set the logging level:
<Parameter name="LoggingLevel" value="DEBUG" override="false"/>
2. Write a servlet context listener to read the parameter
3. Set the logging level accordingly
Place the servlet context listener as the first one in your web.xml so
the new logging level is set before any other logging occurs.
This way your log4j.xml doesn't have to change, and you can just use
an appropriate $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml
to set the desired logging level.
This seems as if it should work.
. . . just my two cents
/mde/
Mark,
I was watching this thread, because I think that the original question has a wider scope,
which has been touched a few times in the past, but to which I have never seen a really
convincing answer.
Example :
I have customers who are security-conscious, and I do not have access to their
servers.
When I need to send them an application update, it must be in the form of a WAR, which the
local sysadmins then deploy on the server.
But in that application, there is a third-party authentication servlet filter, which
requires 3 parameters in web.xml :
- the FQDN of an authentication server
- a login on that authentication server
- a password for that login
This is specific to each customer.
(Of course, there are plenty more parameters in web.xml which are not customer-specific,
but may change with a new version of the app).
So I cannot make a single WAR, and just send it to all. I have (for now) to create a
separate WAR for each customer. And I have to know their password, which they do not like.
Otherwise, my customer sysadmins would have to unpack the WAR, edit web.xml to insert
their specific values, and re-pack the WAR. Which they do not like to do either.
My customers also do not like a solution consisting in having these parameters defined
somehow as JVM properties that must be given on the java command-line, because then any
user with a console on the server can see them by doing a simple "ps -ef".
So, yes, there are a lot of things which they don't like. But such it is, and I am only a
small supplier happy to have them as customer, and I do not want to pick a fight with the
sysadmins. Because that's like picking a fight with a waiter in a restaurant (*).
So is there an easy generic way to solve this, without having to write some specific code
to do it ?
(which I think would also solve the OP's problem)
(*) I once heard one say to a colleague : "Did you see ? he ate it."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
