Hi Martijn,
Thanks about your kind reply.
My requirement is that I want to write the log file path using the
variable APP_HOME which I have already defined in the OS e.g. instead of
writing the log file path as C:\myapp\logs\logfile.log I want to write
it as ${APP_HOME}\logs\logfile.log. The reason is that I have already
tagged C:\myapp as APP_HOME. So every where I want to use the same
variable so that if C:\myapp tomorrow becomes D:\myapp I will just
change at one place i.e. the value of OS variable APP_HOME.
I think this makes my requirements clear.
Regards,
Jitendra
-----Original Message-----
From: Martijn Blankestijn [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 09, 2005 6:29 PM
To: Log4J Users List
Subject: Re: Where to set exernal property referred to in
log4j.properties
Hi Jitendra,
Shared Library: In the Console --> Environment - Shared library is a way
to configure a library consisting of jar files and directories that can
be assigned to a websphere application server instance (JVM) (option 1)
or to an enterprise application (option 2).
This is a way to share a library between all applications within an
application server (library is loaded just once, option 1) or have 1
library for configuration but this library is loaded by each enterprise
application (option 2).
I do not understand why you need the environment variable to configure
log4j. What are you trying to accomplish with that? Is there a
difference in changing the path in the log4j.properties if you want it
changed instead of changing the environment variable? Can you tell us
something about your requirements. Maybe there are alternative
solutions...
Martijn
Jitendra Kharche wrote:
>Hi Martijn and Jake,
>
>Thanks guys. This is a very useful information.
>
>Jake, I don't want to to use the -D option solution for some reason.
>
>Martijn, Actually I am doing the same thing in a different way to make
>same log4j configuration available to EJB and the webapp. I have put
>the log4j.xml in Websphere\AppServer\properties directory and log4j.jar
>in the EAR. In this way the same configuration is available to all of
>my applications deployed in that Websphere.
>
>Earlier I tried keeping log4j.xml in ear as a file (not in a jar), but
>it didn't work. So your solution of using the utility.jar is the
>correct way of doing it that I was missing.
>
>I am not able to understand your second solution. I think I am missing
>the information about Websphere Shared library. What is it and how to
>make it?
>
>But are you sure that this (solution-1 or Solution-2) can solve my
>problem. Because my problem is not about getting the same configuration
>to ejb and webapp. Even with my scheme it is available to both ejb and
>webapp. My problem is that I am setting the JVM system property in
>ServletContextListener (webapp initializer) but before that ejb loads
>and log4j tries to configure itself which fails because the APP_HOME is
>still not set.
>
>Regards,
>Jitendra
>
>
>-----Original Message-----
>From: Martijn Blankestijn [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 09, 2005 11:39 AM
>To: Log4J Users List
>Subject: Re: Where to set exernal property referred to in
>log4j.properties
>
>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:[EMAIL PROTECTED]
>>>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:[EMAIL PROTECTED]
>>>>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:[EMAIL PROTECTED] > >Sent:
>>>>>
>>>>>
>>>Friday, March 25, 2005 8:38 AM > >To: Log4J Users List;
>>>[EMAIL PROTECTED] > >Subject: Re: Where to set exernal property
>>>referred to in >log4j.properties > >On Fri, 25 Mar 2005 00:37:46
>>>-0500, William Noto ><[EMAIL PROTECTED]> > >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: [EMAIL PROTECTED]
>>>>>For additional commands, e-mail:
>>>>>[EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--------------------------------------------------------------------
>>>>-
>>>>
>>>>
>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>For additional commands, e-mail:
>>>>>[EMAIL PROTECTED]
>>>>>
>>>>>
>>>>-------------------------------------------------------------------
>>>>-- To unsubscribe, e-mail:
>>>>[EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>-------------------------------------------------------------------
>>>>-- To unsubscribe, e-mail:
>>>>[EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
