Re: Context parameter override?

[Ognjen Blagojevic]

Andre,

On 10.9.2014 18:43, André Warnier wrote:

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.


Could you move client specific parameters to context.xml (appname.xml)? 
Then, your client could keep the appname.xml at 
$CATALINA_BASE/conf/[enginename]/[hostname]/ directory, and replace war 
file with new versions? There is no need to unpack and repack the war file.


-Ognjen


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Context parameter override?

[sbremal]

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-namelog4jConfigLocation/param-name

param-valuefile:///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.
  

Re: Context parameter override?

[Mark Eggers]

-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-namelog4jConfigLocation/param-name 
 param-valuefile:///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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (MingW32)

iQEcBAEBAgAGBQJUEHZvAAoJEEFGbsYNeTwte+YH/12yWANWhJ2+6MwCKHkdWh5G
AQi20L9LVdjTtWYx+vpZvktqiDSNvYAUTTx2+AJaolo9puqsaSLf5kfR1hTgbGy8
sMrBPLbJY1qY4uZruK5ISPc1I3nbo2j/uDtSpClbfMSGKLUIqcISiCxYwwcb/u5f
UUGXSorSddwCEE2i5Sk8wHpYMcEjRDXa99t6qR5I4Xe6Tb9KG8rJ9yfiB1//snwO
bOGmroKgYRB1sz7cM2xffZNW+3GzN/Z8py0GqdR07+sEDMTYpvVcW0Iu1ebmUtU6
Aw2QTcK9pu4kU+Q2DA7vOycXTdG/8XgFOnQCvhXWRvy63iR1pXiz6KNCZ6qBkrk=
=nU9F
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context parameter override?

[André Warnier]

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-namelog4jConfigLocation/param-name 
param-valuefile:///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

RE: Context parameter override?

[sbremal]

Thanks, I am afraid I read a similar solution earlier which I did not favour 
for multiple reasons:

- it is a run-time configuration question (handled by DevOps, Ops) to have 
various logging levels for various deployed applications on the same Tomcat
- we would like to have full control of logging (which class at what level 
etc.) during run-time, i.e. be able to have per web application Log4j 
configuration file
- writing servlet is beyond the scope of our responsibility (DevOps, Ops)
- keep the Dev and Ops responsibilities separated

What puzzles me is the Context / Parameter feature of Tomcat. (context-param 
from Java is clear.) There are at least 3 locations to define Tomcat level 
parameters:

- server.xml / Host
- webapps / ... / context.xml
- conf/.../myapp.xml

None of these I managed to configure. Is there any working example from Tomcat?

Shall I recommend Dev to hard code a path to the Log4j configuration in 
web.xml, i.e. /usr/local/etc/myapp_log4j.xml, which is potentially a symbolic 
link to an actual file that can stay anywhere on the file system?

 Date: Wed, 10 Sep 2014 09:03:59 -0700
 From: its_toas...@yahoo.com.INVALID
 To: users@tomcat.apache.org
 Subject: Re: Context parameter override?
 
 -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-namelog4jConfigLocation/param-name 
  param-valuefile:///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/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (MingW32)
 
 iQEcBAEBAgAGBQJUEHZvAAoJEEFGbsYNeTwte+YH/12yWANWhJ2+6MwCKHkdWh5G
 AQi20L9LVdjTtWYx+vpZvktqiDSNvYAUTTx2+AJaolo9puqsaSLf5kfR1hTgbGy8
 sMrBPLbJY1qY4uZruK5ISPc1I3nbo2j/uDtSpClbfMSGKLUIqcISiCxYwwcb/u5f
 UUGXSorSddwCEE2i5Sk8wHpYMcEjRDXa99t6qR5I4Xe6Tb9KG8rJ9yfiB1//snwO
 bOGmroKgYRB1sz7cM2xffZNW+3GzN/Z8py0GqdR07+sEDMTYpvVcW0Iu1ebmUtU6
 Aw2QTcK9pu4kU+Q2DA7vOycXTdG/8XgFOnQCvhXWRvy63iR1pXiz6KNCZ6qBkrk=
 =nU9F
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  

Re: Context parameter override?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/10/2014 9:43 AM, André Warnier wrote:
 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-namelog4jConfigLocation/param-name 
 param-valuefile:///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
 

André,

I am not aware of any generic Tomcat mechanism to do this without some
code. The quick and dirty method that I described in the previous
message is Tomcat-specific (which is OK since this is the Tomcat
mailing list).

I can think of a few ways to do this, but all would require some code.

A. Parameters in appname.xml (ie., application-specific context.xml)

You can do this and read the parameters from a listener and configure
a singleton. Then 

Re: Context parameter override?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/10/2014 11:55 AM, Mark Eggers wrote:

 Context ctx = new InitialContext(); Integer maxExemptions =
 ctx.lookup(java:comp/env/maxExemptions);
 
 Try / catch and other issues are left as exercises for the reader.

Urp, at least get the casting correct :-(

Context ctx = new InitialContext();
Integer mE = (Integer)ctx.lookup(java:comp/env/maxExemptions);

. . . and this is why I'm an architect and not a developer
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (MingW32)

iQEcBAEBAgAGBQJUEJ+bAAoJEEFGbsYNeTwt6OsH/RVET2KW8wsXnWeyEc1r/Wuf
0fnbWnLaiFnE3X+pgh+zO48XbUSbRnrlX0BzoTFPNirpTL6O+Q/vgn5Z9kk/xq/E
72uFiHo7nZhAr7acOATskd5IkA/vmVk/tf6JyCG3AMLI7wRIOiqgJlwwoBzK8fqk
IraQ59S96tyYGM56gJd17WA3vF1had+xy2+TclyyJDusU4eSMPqpFDmFvM5Iy5+/
q3QsCwVpO33og27SC+CHZh4CLoTjiLiyYzzzf3P9LkIwb30dEzqjEgv0JGBPaKjp
0Wm4qj+jxOt17Degir238Qom+liJS0L8e2tHrC0EBM+IYMNgKNEt8RvNDz7fRWs=
=jaAJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context parameter override?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Comments inline.

Conventions for this list are to post replies at the end or inline. It
makes reading the thread easier.


On 9/10/2014 10:52 AM, sbre...@hotmail.com wrote:
 Thanks, I am afraid I read a similar solution earlier which I did
 not favour for multiple reasons:
 
 - it is a run-time configuration question (handled by DevOps, Ops)
 to have various logging levels for various deployed applications on
 the same Tomcat

This is quite possible for the solution I proposed. Each application
has its own [appname].xml, so the logging can be changed per application.

 - we would like to have full control of logging (which class at
 what level etc.) during run-time, i.e. be able to have per web
 application Log4j configuration file

Ah, during run-time. I didn't see that requirement in your original
message. That's an entirely different kettle of fish.

The Parameter element of the Context is a Tomcat-specific way to
specify context initialization parameters. As implied by the name
context initialization, they're read once at context start-up and
made available to the context.

Changing them through the life cycle of that context is not possible.
You would have to edit the appname.xml and restart the context.

See my JMX comments to André concerning how to do this on a running
application.

I've hacked together a listener that exposes all of the log4j
information as JMX (based on the following blog post:
http://www.jroller.com/ray/entry/managing_log4j_logging_levels_for).

I then was able to modify the various loggers during run time using
JConsole. Obviously you'll need some sensible initial values.

 - writing servlet is beyond the scope of our responsibility
 (DevOps, Ops)

I agree. You will need the developers to get involved in order to
provide the mechanism for you. I don't know of any configuration-only
mechanism to accomplish this . . .

Hmm . . . hang on a second.

If log4j is configured using configureAndWatch (available via
DOMConfigurator and PropertyConfigurator), then a thread is spawned to
watch the configuration file for changes.

Since this method starts a watchdog thread and there's no way to stop
it in log4j 1.2.x (according to the log4j FAQ), this should not be
used in a J2EE environment where the applications are recycled.

 - keep the Dev and Ops responsibilities separated

Agreed. This is why I think Dev needs to give Ops the handles to tweak
the logging levels (most likely via JMX).

 
 What puzzles me is the Context / Parameter feature of Tomcat.
 (context-param from Java is clear.) There are at least 3 locations
 to define Tomcat level parameters:
 
 - server.xml / Host - webapps / ... / context.xml -
 conf/.../myapp.xml
 
 None of these I managed to configure. Is there any working example
 from Tomcat?

They all work. Doing this at in server.xml means that you'll have to
restart the server when the values change. Doing this in context.xml
(appname.xml) means that you'll have to restart the application when
the values change.

 
 Shall I recommend Dev to hard code a path to the Log4j
 configuration in web.xml, i.e. /usr/local/etc/myapp_log4j.xml,
 which is potentially a symbolic link to an actual file that can
 stay anywhere on the file system?

No. See above concerning the safety and applicability of using
configureAndWatch in a J2EE environment. Changing log4j.xml on the fly
will create thread leaks. Who knows what the environment will be like
once you reload multiple applications using configureAndWatch.

. . . just my two cents
/mde/

 
 Date: Wed, 10 Sep 2014 09:03:59 -0700 From:
 its_toas...@yahoo.com.INVALID To: users@tomcat.apache.org 
 Subject: Re: Context parameter override?
 
 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-namelog4jConfigLocation/param-name 
 param-valuefile:///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

Re: Context parameter override?

[Konstantin Kolinko]

2014-09-10 21:52 GMT+04:00  sbre...@hotmail.com:

 (...)

 What puzzles me is the Context / Parameter feature of Tomcat. (context-param 
 from Java is clear.) There are at least 3 locations to define Tomcat level 
 parameters:

 - server.xml / Host   (1)
 - webapps / ... / context.xml  (2)
 - conf/.../myapp.xml (3)

 None of these I managed to configure.

(1) - wrong. You should not define a Context there.

In Tomcat 6 that you are using, the META-INF/context.xml file (2) is
automatically copied into conf directory of Tomcat (3) when the web
application is being deployed. Once that copying happens modifying the
webapp's file (2) becomes useless. You have to modify the copy.

This copyXml feature was turned off starting with Tomcat 7.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context parameter override?

[sbremal]

I am pretty sure I tried option 3 and Log4j initialization did ignore my 
log4jConfigLocation setting in conf/.../myapp.xml.

What I tried to see in the debug log is the list of context parameters picked 
up at start time. Despite log level was set to FINEST nothing show up in any of 
the Tomcat logs related to my parameter declaration. I shall look into the 
Tomcat code to understand this.

 Date: Thu, 11 Sep 2014 00:20:19 +0400
 Subject: Re: Context parameter override?
 From: knst.koli...@gmail.com
 To: users@tomcat.apache.org
 
 2014-09-10 21:52 GMT+04:00  sbre...@hotmail.com:
 
  (...)
 
  What puzzles me is the Context / Parameter feature of Tomcat. 
  (context-param from Java is clear.) There are at least 3 locations to 
  define Tomcat level parameters:
 
  - server.xml / Host   (1)
  - webapps / ... / context.xml  (2)
  - conf/.../myapp.xml (3)
 
  None of these I managed to configure.
 
 (1) - wrong. You should not define a Context there.
 
 In Tomcat 6 that you are using, the META-INF/context.xml file (2) is
 automatically copied into conf directory of Tomcat (3) when the web
 application is being deployed. Once that copying happens modifying the
 webapp's file (2) becomes useless. You have to modify the copy.
 
 This copyXml feature was turned off starting with Tomcat 7.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
  

Re: Context parameter override?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Responses inline.

On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
 I am pretty sure I tried option 3 and Log4j initialization did
 ignore my log4jConfigLocation setting in conf/.../myapp.xml.

Oh heck, I think I see what you're trying to do. And this isn't going
to work for multiple web applications, since it's a SYSTEM property.

This means you get 1 value for the JVM. The following web page
illustrates this:

http://logging.apache.org/log4j/1.2/manual.html

Read the section called Default Initialization under Tomcat.

Also, what you're configuring is a context initialization parameter
with Parameter and NOT a system property.

In short, if you're trying to direct log4j to read the log4j.xml (or
properties) file from another location, setting a context
initialization parameter will get you absolutely nowhere.

 
 What I tried to see in the debug log is the list of context
 parameters picked up at start time. Despite log level was set to
 FINEST nothing show up in any of the Tomcat logs related to my
 parameter declaration. I shall look into the Tomcat code to
 understand this.

It's not an issue with the Tomcat code. It's how log4j goes about
finding its configuration file.

log4j uses Thread.getContextClassLoader().getResource() to find the
log4j.xml (or properties) file. This means that the file must be in
your classpath. In Tomcat, the search works its way up the class
loader hierarchy.  See the following link for how the class loaders
are searched.

http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

If you want the following:

1. per-application control over log4j logging
2. run-time (as in while the application is running) control
3. thread safety, reliability, and no thread leaks

You will need to do the following:

1. implement a JMX listener to publish the log levels
2. set reasonable levels in log4j.xml found in the context's classpath
3. use a JMX utility to change the log levels during operation

If you want the following:

1. per-application control over log4j logging
2. change log levels while the application is not running

Then you have some options (and I hope you start / stop logging in a
servlet context listener).

Place the log4j.xml (or properties) file in the WAR file. When it's
deployed (if the WAR is exploded), you can then edit it and restart
the context.

Place the log4j.xml (or properties) file outside the WAR file and do
the following (again, this will have to be facilitated by the Dev group):

1. Create a context init parameter (most easily in the Parameter
   element in context.xml).

2. The init parameter will give the path to the file

3. Read that parameter in a servlet context listener

4. Pass that to the Configurator's configure(String filename) method

Again, you will have to tell log4j to find the configuration some
place other than it normally looks (classpath or the SYSTEM property
log4j.configuration).

Here's how I manage things.

1. Maven project for deploy
   a. accepts a parameter to select appropriate logging levels
   b. this selects a properties file to filter a log4j template
   c. properties file is under version control
   d. accepts a parameter for the version to deploy
   e. accepts a parameter for where to deploy
2. Parameterized Jenkins job
   a. runs the Maven project
   b. drop-down menu for IT (internal test), UAT, PROD
   c. drop-down menu for version (no SNAPSHOTS in PROD!)
   d. sends email to dev responsible, ops, business lead
  1. what was deployed
  2. where it was deployed
  3. when it was deployed
  4. who deployed it (no shared accounts on Jenkins)

I use parallel deployment with Tomcat 7 and use the Jenkins build
number to increment the value.

I'm working on updating the incident tracking system automatically
from Jenkins, but I'm just learning Groovy and the tracking system
doesn't have a robust API.

. . . just my two cents
/mde/

 
 Date: Thu, 11 Sep 2014 00:20:19 +0400 Subject: Re: Context
 parameter override? From: knst.koli...@gmail.com To:
 users@tomcat.apache.org
 
 2014-09-10 21:52 GMT+04:00  sbre...@hotmail.com:
 
 (...)
 
 What puzzles me is the Context / Parameter feature of Tomcat.
 (context-param from Java is clear.) There are at least 3
 locations to define Tomcat level parameters:
 
 - server.xml / Host   (1) - webapps / ... / context.xml  (2) -
 conf/.../myapp.xml (3)
 
 None of these I managed to configure.
 
 (1) - wrong. You should not define a Context there.
 
 In Tomcat 6 that you are using, the META-INF/context.xml file (2)
 is automatically copied into conf directory of Tomcat (3) when
 the web application is being deployed. Once that copying happens
 modifying the webapp's file (2) becomes useless. You have to
 modify the copy.
 
 This copyXml feature was turned off starting with Tomcat 7.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (MingW32)

iQEcBAEBAgAGBQJUENScAAoJEEFGbsYNeTwt+lwH/iUxrY8FoVTmK2hK4ewPOhNs

Re: Context parameter override?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/10/14 6:45 PM, Mark Eggers wrote:
 Responses inline.
 
 On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
 I am pretty sure I tried option 3 and Log4j initialization did 
 ignore my log4jConfigLocation setting in conf/.../myapp.xml.
 
 Oh heck, I think I see what you're trying to do. And this isn't
 going to work for multiple web applications, since it's a SYSTEM
 property.
 
 This means you get 1 value for the JVM. The following web page 
 illustrates this:
 
 http://logging.apache.org/log4j/1.2/manual.html

If the OP is using log4j with multiple web applications and wants to
have log4j.jar at the Tomcat level instead of at the webapp level,
then log4j 2.x is what he wants: it's got much better support for
things like multiple ClassLoaders, etc.

Using default initialization for log4j is just a Bad Idea in general.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIbBAEBCAAGBQJUEONXAAoJEBzwKT+lPKRYvtMP8wZZjCGcyHty/R3gDQWsfh+N
3D4A+V0sRGi2xNb4uEpdwd7yRRAc6m7D8IRodzJfYM2mLCKLl4vZxzbcGyfX3+H8
OHpRy9dD9g33QhFIGtz2DBjGx4O0dZbF9Crjt9BsVbMORPwQgS0Z8rxgEj3nSXzp
uR1E/9Cyv0WOsKMjkIGFrdvRvyibipaJ6q3/uKzBmhGsk9LdBlUhzzN6YpYnkV1M
S5Ca2wosTTEDmzapL34dI7OtjnZNgfl4egqD9u2aMvARTlQMfVG6A1v/LRVhXbDU
AtQSxCrspbEeVZQjyTxADWrh/3eAQXehaaRrfej/gHoEZKNhxMqDvbmFFhHwl2YZ
upFWiWSWOP4xBbA4pHnstd0lp6zSygO7mXjZPYfeW9V/Qac1FBM784UQWtq9V1RO
s0eeyhknLYcIr8d55EXMXZ1KDbtpGOC/2qXwZMPktsk+CQNyUwBiNa9BR6GQxGr2
mMGr3LbDVM/cfTNmmbTR5YQVnt4CyausF/Wrgo2WKCpD2fL8Kc4yxG6g1d9tqk0j
MkPSn9UKjhEXgFDSpf+3Fyf5GrPK3z+QTAt5xU9rYf1x6jIocRuxCgx7bLpuUplH
Pj9b0OeJMELrJtvBCCEWDjpCKdPwcLGQVJBTe5i2jH0/9P3/1lTLU+xrDbat7CCJ
qTo97nFTnd9FwoSnazM=
=HLyL
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context parameter override?

[Mark Eggers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris,

On 9/10/2014 4:48 PM, Christopher Schultz wrote:
 Mark,
 
 On 9/10/14 6:45 PM, Mark Eggers wrote:
 Responses inline.
 
 On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
 I am pretty sure I tried option 3 and Log4j initialization did
  ignore my log4jConfigLocation setting in conf/.../myapp.xml.
 
 Oh heck, I think I see what you're trying to do. And this isn't 
 going to work for multiple web applications, since it's a SYSTEM 
 property.
 
 This means you get 1 value for the JVM. The following web page 
 illustrates this:
 
 http://logging.apache.org/log4j/1.2/manual.html
 
 If the OP is using log4j with multiple web applications and wants
 to have log4j.jar at the Tomcat level instead of at the webapp
 level, then log4j 2.x is what he wants: it's got much better
 support for things like multiple ClassLoaders, etc.
 
 Using default initialization for log4j is just a Bad Idea in
 general.
 
 -chris
 

Agreed. However since the original poster is running under Tomcat 6, I
went ahead and assumed (insert appropriate comment here) that the
included library was 1.2.x.

If it's 2.x, then my comments should be factored accordingly.

So B, which version of log4j is being included in your applications?
Are you using one log4j JAR in $CATAINA_HOME/lib (or $CATALINA_BASE/lib)?

. . . discovery, it's not just for breakfast anymore
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (MingW32)

iQEcBAEBAgAGBQJUEOWQAAoJEEFGbsYNeTwtXmUH/3HrbaTGrvgSGdY7lWZk/I/y
6LKBNWyxVSHkdn4XhIJryDd1h6UihnA90Z+3UlOwc3jyKh95zdlqYj32cDs+tEeQ
Qlhjz7UlT5JYPRVjp4ksK/PQ6S9sgFefB+gXWABVBsawlpy0f/tiWknKuMyGVGFM
eEEX+aghV/hj6qI8u31KyaxwCjnxv4E+EQ+hBZ5ZkW/ElmNlMf1gI/uF+sDAL2LI
eQ/1MD24DzkpU/lJZ0nCbj3L+YwP+lACOQlyZW8ptHSHgnGLwcW8Se+JrHF09/qD
wmmOkXyNtKXiFj2wvCwF49Wle1FcCCmOJqUj4e9zTiAf5jlIjtfkPNLQ7wXkqYY=
=PVAv
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context parameter override?

[sbremal]

We have Log4j packaged within the WAR for each of the deployed applications. 
Under run-time configuration I mean editing the standard log4j.xml which is 
re-read by Tomcat. (I.e. we do not want to reimplement any log level 
configuration in servlet configuraton, what we  want is to pass the location of 
that log4j file outside the WAR and be able to change this location without 
touching the webapps directory, otherwise we will lose it with redeployment.)

What worked perfectly is the log4jConfigLocation context-param in the web.xml. 
As far as I understand this mechanism comes from Spring (class 
Log4jWebConfigurer), which is fine, as all our applications use Spring.

What does not work is to override log4jConfigLocation from the 
conf/.../myapp.xml context file (after Tomcat copies it there) using the 
Parameter element. Anyone experience with this exact problem? Or, how to debug 
it?

 Date: Wed, 10 Sep 2014 16:58:08 -0700
 From: its_toas...@yahoo.com.INVALID
 To: users@tomcat.apache.org
 Subject: Re: Context parameter override?
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Chris,
 
 On 9/10/2014 4:48 PM, Christopher Schultz wrote:
  Mark,
  
  On 9/10/14 6:45 PM, Mark Eggers wrote:
  Responses inline.
  
  On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
  I am pretty sure I tried option 3 and Log4j initialization did
   ignore my log4jConfigLocation setting in conf/.../myapp.xml.
  
  Oh heck, I think I see what you're trying to do. And this isn't 
  going to work for multiple web applications, since it's a SYSTEM 
  property.
  
  This means you get 1 value for the JVM. The following web page 
  illustrates this:
  
  http://logging.apache.org/log4j/1.2/manual.html
  
  If the OP is using log4j with multiple web applications and wants
  to have log4j.jar at the Tomcat level instead of at the webapp
  level, then log4j 2.x is what he wants: it's got much better
  support for things like multiple ClassLoaders, etc.
  
  Using default initialization for log4j is just a Bad Idea in
  general.
  
  -chris
  
 
 Agreed. However since the original poster is running under Tomcat 6, I
 went ahead and assumed (insert appropriate comment here) that the
 included library was 1.2.x.
 
 If it's 2.x, then my comments should be factored accordingly.
 
 So B, which version of log4j is being included in your applications?
 Are you using one log4j JAR in $CATAINA_HOME/lib (or $CATALINA_BASE/lib)?
 
 . . . discovery, it's not just for breakfast anymore
 /mde/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (MingW32)
 
 iQEcBAEBAgAGBQJUEOWQAAoJEEFGbsYNeTwtXmUH/3HrbaTGrvgSGdY7lWZk/I/y
 6LKBNWyxVSHkdn4XhIJryDd1h6UihnA90Z+3UlOwc3jyKh95zdlqYj32cDs+tEeQ
 Qlhjz7UlT5JYPRVjp4ksK/PQ6S9sgFefB+gXWABVBsawlpy0f/tiWknKuMyGVGFM
 eEEX+aghV/hj6qI8u31KyaxwCjnxv4E+EQ+hBZ5ZkW/ElmNlMf1gI/uF+sDAL2LI
 eQ/1MD24DzkpU/lJZ0nCbj3L+YwP+lACOQlyZW8ptHSHgnGLwcW8Se+JrHF09/qD
 wmmOkXyNtKXiFj2wvCwF49Wle1FcCCmOJqUj4e9zTiAf5jlIjtfkPNLQ7wXkqYY=
 =PVAv
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org