You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jacob Kjome <ho...@visi.com> on 2005/06/09 04:46:15 UTC
RE: Where to set exernal property referred to in
log4j.properties
At 11:42 AM 6/8/2005 +0530, you wrote:
>
>Hi,
>
>Thanks Jake and James.
>
>I have noticed following:
>I have a J2EE app packaged as EAR file that has a EJB module, a WEB
>module and some AppClient modules.
>
>After I have done the steps I discussed in my last mail, from the
>websphere logs I came to know that the EJB module is getting initialized
>before the servlet context listener. So I removed the EJB module from
>the EAR and redeployed the application. Now the mechanism works fine.
>Log files are getting created in the path ${APP_HOME}\logs\logfile.log.
>
>The reason I think is that in the ejb I am creating a static instance of
>Logger, so the log4j system starts to initialize itself and doesn't
>understand the file path ${APP_HOME}\logs\logfile.log because APP_HOME
>is not yet set in JVM system properties.
>
It probably wouldn't matter whether it is static or not in the EJB since
the container creates the instance right away, no?
>Is there a way of getting out of it?
Sure, if you use a -D parameter to set the JVM system variable when you
start up the appserver, the variable will exist at all times. BTW, can
your EJB actually see the log4j.xml file? If it is sitting in the webapp,
I wouldn't think that it would be available for the EJB to see unless
Websphere uses something like JBoss' unified classloader. To use a single
instance of Log4j for the whole app, one would have log4j.jar and log4j.xml
no further down the classloader tree than the EAR classloader. And in
order to separate this from the appserver's logging (assuming it uses
log4j), you would need to use a repository selector. WAR logging is much
simpler, especially if the server implements parent-last classloading
behavior like Tomcat does. Of course this means separate logging configs
for server and webapp (at least different instances of Log4j, since you
could use the same config file by not including it in the webapp and
loading a common one, however, these would still be in separate logger
repositories).
>For me this works fine for now,
>since I am not using the EJB for some reason. But in future I will have
>to use it and it might be a problem again.
>
Logging at an EJB level is always an interesting endeavor. We don't use
too many EJB's so I haven't explored it that much, but I'd be curious as to
the approach others have taken. Might make for a good wiki entry?
Jake
>Regards,
>Jitendra
>
>-----Original Message-----
>From: Jacob Kjome [mailto:hoju@visi.com]
>Sent: Wednesday, June 08, 2005 7:47 AM
>To: Log4J Users List
>Subject: RE: Where to set exernal property referred to in
>log4j.properties
>
>At 06:00 PM 6/7/2005 +0530, you wrote:
> >
> >Hi Jacob,
> >
> >What is autoconfiguration?
>
>As James said, refer to the docs (link provided in his response)
>
> >I am using the same solution as you have suggested below for the same
>>problem that I want the log file path to contain ${MY_APP_HOME} e.g.
> >${MY_APP_HOME}\logs\logfile.log.
> >But it is not working. I am using Websphere5.0.
> >1. I have set an OS environment variable MY_APP_HOME=3D"C:\myapp"
> >2. Implemented ServletContextListener and in contextInitialized()
>method >got the value of this OS env var and set it into JVM
>properties.
> >3. The log4j.xml file contains the log file path as
>>${MY_APP_HOME}\logs\logfile.log.
> >
> >What is going wrong. One thing I have noticed from the logs is that,
>>log4j system is trying to initialize before the ServletContext is
>>initialized.
> >
>
>Actually, I mentioned this below. If you have the config file in the
>classpath, log4j will autoconfigure itself in a static block. This will
>happen before your servlet context listener has a chance to do anything.
>What I tend to do is put a dummy log4j.xml config file in the classpath
>which is minimal and pretty much turns off all logging in the root
>logger, and then perform manual configuration. Having the file in the
>classpath makes sure no other log4j config file get picked up (in case
>some library is improperly placing their own config file in the
>classpath). In any case, the manual configuration afterward should have
>reset the logging configuration so your config should have worked.
>
>BTW, the point about the OS system variable was more so you can set
>CATALINA_OPTS (speaking of Tomcat here) once and be done. Then, if you
>change a path, CATALINA_OPTS will pick it up automatically. It was sort
>of an aside. The main thing is that you can set -D parameters which
>will set JVM system properties, such as "-DMY_APP_HOME=/path/to/app".
>In that case, autoconfiguration would pick that system property up
>because it would exist before the Log4j static block runs
>autoconfiguration.
>
>One other thing to check is that the "/path/to/app/logs" directory
>exists. If you are expecting Log4j to create it for you if it doesn't
>already exist, you are mistaken. Log4j makes no attempt to create
>directories. That is your code's responsibility to do before
>configuration takes place.
>
>Jake
>
> >Please help.
> >
> >Regards,
> >Jitendra
> >
> >-----Original Message-----
> >From: Jacob Kjome [mailto:hoju@visi.com]
> >Sent: Friday, March 25, 2005 8:44 PM
> >To: Log4J Users List
> >Subject: RE: Where to set exernal property referred to in
>>log4j.properties > >At 09:33 AM 3/25/2005 -0500, you wrote:
> > >Thanks for the reply, James. I agree with you that it wouldn't be
>>>non-standard but since I don't maintain our tomcat implementation I
>was >>looking to see if there might be another way.
> >
> >Have you looked into using CATALINA_OPTS? Just set said variable as
>an >OS system property and provide any command line arguments you want.
> >Tomcat's scripts will pick this up and add it to the Tomcat startup
>>script. This means you can add custom command line args without having
>>to change the Tomcat distribution at all.
> >
> >You can also use a ServletContextListener to set up a system property,
>>which you refer to the log4j config file, before manual configuration
>is >performed. Note that autoconfiguration probably would not work in
>this >case since the system property will have been set *after*
>>autoconfiguration has taken place.
> >
> > >
> > >Maybe making the logs relative to catalina.home is the right idea.
>I >>suppose that my only concern though is that I'm using my primary
>log >file by >both my web application and another external java
>application >code. I >mentioned this a couple days ago and someone
>suggested that >sharing one log >file between two applications is a
>bad idea and that >the logs would become >garbled. Is that really so?
>I thought that it >was OK to share a log >between different JVMs since
>the log includes >thread identifiers.
> > >
> >
> >As I understand it, the only time you need to worry about File
>>contention is between two separate JVM's. However, you will need to
>>make sure that in one config file you don't set the FileAppender to
>>append=true and append=false in another. So, you might want to point
>at >different files per application even if there is no thread level
>file >contention. You can still log you files relative to
>catalina.home (or >catalina.base), since that is a JVM system variable
>that Tomcat provides >for you automatically at startup.
> >
> >Jake
> >
> > >I'm probably going to move the applications that are outside the web
>>>application to a model whereby they are executed from URLs anyway so
>in >the >future I suppose that risk will be mitigated.
> > >
> > >
> > >-----Original Message-----
> > >From: James Stauffer [mailto:stauffer.james@gmail.com] > >Sent:
>Friday, March 25, 2005 8:38 AM > >To: Log4J Users List;
>wnoto@openfinance.com > >Subject: Re: Where to set exernal property
>referred to in >log4j.properties > >On Fri, 25 Mar 2005 00:37:46
>-0500, William Noto ><wn...@openfinance.com> > >wrote:
> > >> My operations team is concerned about setting the property
>>externally at >the >> user level when we start Tomcat because they do
>>not want to run a >> non-standard implementation.
> > >That is equivalent to setting an environement variable and wouldn't
>>>make it a "non-standard implementation."
> > >
> > >> I have tried a number of things that I thought >> might work
>>including setting the property through the web.xml's >> context-param
>>tag and setting it in the <context> at the server.xml level >> but
>>always without success.
> > >Can you just use a relative path or chose a path relative to
>>>${catalina.home} ?
> > >
> > >--
> > >James Stauffer
> > >Are you good? Take the test at http://www.livingwaters.com/good/ >
>> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> > >
> >
>>---------------------------------------------------------------------
> > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Where to set exernal property referred to in log4j.properties
Posted by Martijn Blankestijn <m....@hccnet.nl>.
Hi,
I have had some experience with Log4j in WebSphere 5.1. The EJB's will
always be loaded first. This cannot be changed as far as I know.
The option of adding the property to the WebSphere Application Server
process (App Server - Process Definition ...) will work. This might
cause a problem if you have different applications for which you want to
set the APP_HOME variable.
Here is the scheme I used. I had the same logging configuration for the
EJB and the webapp. I put log4j.properties in a utility.jar of the ear.
I put the utility.jar and the log4j.jar in the ear. Made references to
the utility.jar and log4j.jar in the manifest files of the EJB (and
probably in the war (not sure anymore ;-))).
This way both the EJB and WAR will find the same configuration.
In another project I put the log4j.jar and log4j.properties in a
directory and made a WebSphere shared library. I added this library to
the enteprise application so they will be added to the classpath of the
enterprise application. This way the ejb and the war are both able to
find the configuration.
Martijn
Jacob Kjome wrote:
> At 11:42 AM 6/8/2005 +0530, you wrote:
> >
> >Hi,
> >
> >Thanks Jake and James.
> >
> >I have noticed following:
> >I have a J2EE app packaged as EAR file that has a EJB module, a WEB
> >module and some AppClient modules.
> >
> >After I have done the steps I discussed in my last mail, from the
> >websphere logs I came to know that the EJB module is getting initialized
> >before the servlet context listener. So I removed the EJB module from
> >the EAR and redeployed the application. Now the mechanism works fine.
> >Log files are getting created in the path ${APP_HOME}\logs\logfile.log.
> >
> >The reason I think is that in the ejb I am creating a static instance of
> >Logger, so the log4j system starts to initialize itself and doesn't
> >understand the file path ${APP_HOME}\logs\logfile.log because APP_HOME
> >is not yet set in JVM system properties.
> >
>
> It probably wouldn't matter whether it is static or not in the EJB
> since the container creates the instance right away, no?
>
> >Is there a way of getting out of it?
>
> Sure, if you use a -D parameter to set the JVM system variable when
> you start up the appserver, the variable will exist at all times.
> BTW, can your EJB actually see the log4j.xml file? If it is sitting
> in the webapp, I wouldn't think that it would be available for the EJB
> to see unless Websphere uses something like JBoss' unified
> classloader. To use a single instance of Log4j for the whole app, one
> would have log4j.jar and log4j.xml no further down the classloader
> tree than the EAR classloader. And in order to separate this from the
> appserver's logging (assuming it uses log4j), you would need to use a
> repository selector. WAR logging is much simpler, especially if the
> server implements parent-last classloading behavior like Tomcat does.
> Of course this means separate logging configs for server and webapp
> (at least different instances of Log4j, since you could use the same
> config file by not including it in the webapp and loading a common
> one, however, these would still be in separate logger repositories).
>
> >For me this works fine for now,
> >since I am not using the EJB for some reason. But in future I will have
> >to use it and it might be a problem again.
> >
>
> Logging at an EJB level is always an interesting endeavor. We don't
> use too many EJB's so I haven't explored it that much, but I'd be
> curious as to the approach others have taken. Might make for a good
> wiki entry?
>
>
> Jake
>
> >Regards,
> >Jitendra
> >
> >-----Original Message-----
> >From: Jacob Kjome [mailto:hoju@visi.com]
> >Sent: Wednesday, June 08, 2005 7:47 AM
> >To: Log4J Users List
> >Subject: RE: Where to set exernal property referred to in
> >log4j.properties
> >
> >At 06:00 PM 6/7/2005 +0530, you wrote:
> > >
> > >Hi Jacob,
> > >
> > >What is autoconfiguration?
> >
> >As James said, refer to the docs (link provided in his response)
> >
> > >I am using the same solution as you have suggested below for the same
> >>problem that I want the log file path to contain ${MY_APP_HOME} e.g.
> > >${MY_APP_HOME}\logs\logfile.log.
> > >But it is not working. I am using Websphere5.0.
> > >1. I have set an OS environment variable MY_APP_HOME=3D"C:\myapp"
> > >2. Implemented ServletContextListener and in contextInitialized()
> >method >got the value of this OS env var and set it into JVM
> >properties.
> > >3. The log4j.xml file contains the log file path as
> >>${MY_APP_HOME}\logs\logfile.log.
> > >
> > >What is going wrong. One thing I have noticed from the logs is that,
> >>log4j system is trying to initialize before the ServletContext is
> >>initialized.
> > >
> >
> >Actually, I mentioned this below. If you have the config file in the
> >classpath, log4j will autoconfigure itself in a static block. This will
> >happen before your servlet context listener has a chance to do anything.
> >What I tend to do is put a dummy log4j.xml config file in the classpath
> >which is minimal and pretty much turns off all logging in the root
> >logger, and then perform manual configuration. Having the file in the
> >classpath makes sure no other log4j config file get picked up (in case
> >some library is improperly placing their own config file in the
> >classpath). In any case, the manual configuration afterward should have
> >reset the logging configuration so your config should have worked.
> >
> >BTW, the point about the OS system variable was more so you can set
> >CATALINA_OPTS (speaking of Tomcat here) once and be done. Then, if you
> >change a path, CATALINA_OPTS will pick it up automatically. It was sort
> >of an aside. The main thing is that you can set -D parameters which
> >will set JVM system properties, such as "-DMY_APP_HOME=/path/to/app".
> >In that case, autoconfiguration would pick that system property up
> >because it would exist before the Log4j static block runs
> >autoconfiguration.
> >
> >One other thing to check is that the "/path/to/app/logs" directory
> >exists. If you are expecting Log4j to create it for you if it doesn't
> >already exist, you are mistaken. Log4j makes no attempt to create
> >directories. That is your code's responsibility to do before
> >configuration takes place.
> >
> >Jake
> >
> > >Please help.
> > >
> > >Regards,
> > >Jitendra
> > >
> > >-----Original Message-----
> > >From: Jacob Kjome [mailto:hoju@visi.com]
> > >Sent: Friday, March 25, 2005 8:44 PM
> > >To: Log4J Users List
> > >Subject: RE: Where to set exernal property referred to in
> >>log4j.properties > >At 09:33 AM 3/25/2005 -0500, you wrote:
> > > >Thanks for the reply, James. I agree with you that it wouldn't be
> >>>non-standard but since I don't maintain our tomcat implementation I
> >was >>looking to see if there might be another way.
> > >
> > >Have you looked into using CATALINA_OPTS? Just set said variable as
> >an >OS system property and provide any command line arguments you want.
> > >Tomcat's scripts will pick this up and add it to the Tomcat startup
> >>script. This means you can add custom command line args without having
> >>to change the Tomcat distribution at all.
> > >
> > >You can also use a ServletContextListener to set up a system property,
> >>which you refer to the log4j config file, before manual configuration
> >is >performed. Note that autoconfiguration probably would not work in
> >this >case since the system property will have been set *after*
> >>autoconfiguration has taken place.
> > >
> > > >
> > > >Maybe making the logs relative to catalina.home is the right idea.
> >I >>suppose that my only concern though is that I'm using my primary
> >log >file by >both my web application and another external java
> >application >code. I >mentioned this a couple days ago and someone
> >suggested that >sharing one log >file between two applications is a
> >bad idea and that >the logs would become >garbled. Is that really so?
> >I thought that it >was OK to share a log >between different JVMs since
> >the log includes >thread identifiers.
> > > >
> > >
> > >As I understand it, the only time you need to worry about File
> >>contention is between two separate JVM's. However, you will need to
> >>make sure that in one config file you don't set the FileAppender to
> >>append=true and append=false in another. So, you might want to point
> >at >different files per application even if there is no thread level
> >file >contention. You can still log you files relative to
> >catalina.home (or >catalina.base), since that is a JVM system variable
> >that Tomcat provides >for you automatically at startup.
> > >
> > >Jake
> > >
> > > >I'm probably going to move the applications that are outside the web
> >>>application to a model whereby they are executed from URLs anyway so
> >in >the >future I suppose that risk will be mitigated.
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: James Stauffer [mailto:stauffer.james@gmail.com] > >Sent:
> >Friday, March 25, 2005 8:38 AM > >To: Log4J Users List;
> >wnoto@openfinance.com > >Subject: Re: Where to set exernal property
> >referred to in >log4j.properties > >On Fri, 25 Mar 2005 00:37:46
> >-0500, William Noto ><wn...@openfinance.com> > >wrote:
> > > >> My operations team is concerned about setting the property
> >>externally at >the >> user level when we start Tomcat because they do
> >>not want to run a >> non-standard implementation.
> > > >That is equivalent to setting an environement variable and wouldn't
> >>>make it a "non-standard implementation."
> > > >
> > > >> I have tried a number of things that I thought >> might work
> >>including setting the property through the web.xml's >> context-param
> >>tag and setting it in the <context> at the server.xml level >> but
> >>always without success.
> > > >Can you just use a relative path or chose a path relative to
> >>>${catalina.home} ?
> > > >
> > > >--
> > > >James Stauffer
> > > >Are you good? Take the test at http://www.livingwaters.com/good/ >
> >> >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > > >
> > > >
> > >
> >>---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org