Well, I've tried, but I have some "bugs"...
I deployed two applications, both with their own log4j.jar, and
properties file, and I put an other to ${catalina.home}/common/classes,
and ${catalina.home}/common/lib. It seems to be working except the
following "bugs":
1.
INFO: Starting Servlet Engine: Apache Tomcat/5.5.17
Aug 16, 2006 6:01:55 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
log4j:WARN No appenders could be found for logger
(org.apache.commons.digester.Digester.sax).
log4j:WARN Please initialize the log4j system properly.
2. If i set rootLogger for any of the applications, it won't log anything
3. The common log4j logs only the tomcat logs and can't see the
servlet's logs (this is because of the classloader)
4. the app's loggers don't log their own hivemind services' logs so it
seems that they can't see them
I've tried the log4j from both commons and shared, but it didn't work
When I tried to use log4j from ${catalina.home}/shared only, I
recognized, that all of the hivemind services' logs seems to have
${module_id}.${service_id} classpath. And if the service has been
called, it creates a log: "Constructing core service implementation for
service x.y"
Does anybody know something about hivemind?
Does it make its own implementation of services really? Because this is
my only explanation for the phenomena written above.
Jacob Kjome wrote:
Quoting James Stauffer <[EMAIL PROTECTED]>:
On 8/15/06, Takacs Bence <[EMAIL PROTECTED]> wrote:
> 1. Only have log4j.properties and log4j.jar under tomcat/shared or
> tomcat/common
What do you mean 'or'???
Two directories for two different functions. One for tomcat 'inner'
configuration (tomcat/common), and one for 'applications' configuration
(tomcat/shared). As far as I know they are not in 'or' relation...
Maybe I can put only one log4j.jar, but what about the properties file???
I adminit that I don't know the difference between those two
directories but I have my log4j.jar in tomcat/common and the apps can
access log4j classes just fine. Basically for this option I meant to
put it in a directory so that it is in both the classpath for both
tomcat and the apps.
shared/classes is seen by apps. common/classes is seen by both Tomcat and apps.
As far as apps are concerned, though, I wouldn't bet the farm on an app using
log4j.properties from one or the other. It would all depend on what gets
placed first in the classpath. If you have it in common/classes for Tomcat's
sake, I shared/classes is not a proper place to put another copy for apps'
sake. WEB-INF/classes is the place to put them... as long as you also put
log4j.jar in WEB-INF/lib at the same time. The reason why this works (for
Tomcat standalone) is that Tomcat implements child-first classloading. If you
run Tomcat under, for instance, JBoss however, you cannot count on this.
Is Log4j such sensitive??? Or am I the one who doesn't understand the
point?
You need to be aware of how classloaders work to understand why Log4j can't help
but do what it is doing. It's not a bug. We all get your point. In any case,
it should work, as long as you are using Tomcat standalone with its default
behavior of child-first classloading when you have your config file in
WEB-INF/classes and log4j.jar in WEB-INF/lib. Even if you have
log4j.properties in common/classes or shared/classes, then one in
WEB-INF/classes should take precedence. The fact that you are finding it
doesn't leads me to one of two conclusions...
1. You aren't using Tomcat standalone, but Tomcat integrated with JBoss or some
IDE that is changing the default classloading behavior for child-first to
parent-first.
2. There *is* a log4j.xml file somewhere out there hiding in some jar file that
you are unaware of. Log4j is using it instead of log4j.properties. For this
reason, I implore you to use a log4j.xml file if for no other reason than to
rule out this possibility.
Basically you can have only 1 config file and 1 log4j.jar in the
classpath.
No, per distinct classloader.
The log4j core classes only try to configure themselves
once so you only want 1 log4j.jar and 1 log4j config file in the
classpath.
Again, per distinct clasloader.
If you have multiple then it might not use the config file
that you expect.
ditto what I said two times already.
Since the app server has different classpaths for
different parts you end up with these options for where you want the
log4j files.
Ahh... I think you are using "classpath" to mean "classloader". Ok. Basically,
what you have said is correct. Just need to distinguish "classpath" from
"classloader".
Jake
> Try running with -Dlog4j.debug. That should give you more info about
> the problem.
> It is a command line option so that depends on how you run Tomcat. I
> put it in the Java tab of the "Configure Tomcat" applicaton.
So I'have called catalina with theese switch. And then? I experienced
nothing different...
When you use -Dlog4j.debug log4j will print extra info to standard output.
Thanks:
Bence
James Stauffer wrote:
I don't think it will work to have log4j.jar under
webapps/app/WEB-INF/lib and expect those locations of log4j.properties
to be used.
You have 2 choices that I know will work:
1. Only have log4j.properties and log4j.jar under tomcat/shared or
tomcat/common
2. Only have log4j.properties and log4j.jar under webapps/<app>/WEB-INF
For #2 you might be able to put log4j.properties and log4j.jar
someplace that tomcat can see them but not the apps (server?).
On 8/15/06, Takacs Bence <[EMAIL PROTECTED]> wrote:
No log4j.xml, and only the two log4j.properties:
- one in the /tomcat/shared/classes for tomcat inner logs
- one in the /tomcat/common/classes for tomcat applications logs
I make both of them after the error message...
Thanks:
Bence
Jacob Kjome wrote:
Is there a log4j.xml anywhere on the classpath (in the default
package, that
is)? Look in directories and jars. I would suggest changing to an
XML config
file because Log4j looks for it first. If it doesn't find
log4j.xml, then it
looks for log4j.properties. I've seen this happen so often to users
that it is
the first thing I ask them.
Jake
Quoting James Stauffer <[EMAIL PROTECTED]>:
Try running with -Dlog4j.debug. That should give you more info about
the problem.
On 8/14/06, Takacs Bence <[EMAIL PROTECTED]> wrote:
No
James Stauffer wrote:
Is there a log4j.jar under shared or common?
On 8/14/06, Takacs Bence <[EMAIL PROTECTED]> wrote:
I _only_ moved log4j.properties from shared/classes to two
different
webapps/app/WEB-INF/classes directory. In other words I deleted
the
original file and made two different copies (with the required
modifications of course).
Both projects has it's own log4j.jar too.
Thanks:
Bence
James Stauffer wrote:
Did you move log4j.properties also? You will need to do that
too.
On 8/14/06, Takacs Bence <[EMAIL PROTECTED]> wrote:
Hello
James Stauffer wrote:
I meant different config files. If you move the
lib/log4j.jar and
classes/log4j.properties from the shared classpath (i.e.
tomcat/common) to each webapp (i.e. webapps/app/WEB-INF) then
each app
will use a separate config file.
I deleted the common /tomcat/shared/classes/log4j.properties,
and put
different properties file to the different projects
(webapps/app/WEB-INF/classes). But it seems that only one send
logs
out
of it. I can't get the other one's logs neither on the console
nor on
ftp. Maybe on tcp it could be problem that I set the same port
for
the
two appenders but what about the console???
Any idea?
Thanks:
Bence
---------------------------------------------------------------------
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]
--
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]
--
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]
