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]
