Separate log4j.properties not allowed?

[neut6o1]

I just found out from WarJot that jboss has integrated log4j into itself as of 2.4. I have just updated to that version and it seems as if there is no way to have your own log4j.properties file(mine is called kietralog4j.properties after the company I work for). I have a system property in run.bat that says "log4j.configuration=kietralog4j.properties".

Now that log4j is integrated however, my system property is ignored and all of my logging through log4j is using the jboss log4j.properties. I would like to keep jboss's logging settings seperate from my applications logging settings. Is there any way to do this? I tried changing jboss.conf to have an argument under the log4jservice mlet, but that just seemed to give screwy logging that used my properties file was logging the threshold correctly but not the conversion pattern. It also changed the jboss logging to my properties file when I wanted to still use jboss's properties file for jboss logs. Thanks for any help.

Chris Heady

[marc.fleury]

I don't see how JBoss changes the configuration loading of log4j, as far as I know it just instanciates the log4j stuff and off it goes, but i could be wrong.

How do you do that in your own applications?

Warjort, if you are reading this, make sure that 3.0 allows for this behavior (if indeed there is anything that we need to do from the loading for the log4j). The authority on log4j is scott but he is working on a training and will be giving a training next week.

Let me know if you want to sort it out,

marcf

[adrian.brock]

Hi,

Looks like I've opened a can of worms :-)

What are you trying to do with your own properties?
As far as I am aware there can be only one
log4j configuration in a VM.

You will have to somehow merge the two property
files.

JBoss does

log4j.rootCategory=DEBUG, Default, Console

This means all logging at debug or above goes to
the default and console appender defined later down.

To define your own appender you will have to do
something like
log4j.category.com.kietra=INFO, Kietra
Then configure the Kietra appender.

The trouble is that all com.kietra loggings will
also go in the jboss logs, because they are logging
from the root category.

It is possible to programatically set an
additivity flag on a category to stop this.
But I'm not sure how to do this in the
properites file.
The following doesn't work :-(

log4j.category.com.kietra.Additivity=false

I'm not sure what is going on with the
conversion pattern?

Regards,
Adrian

[neut6o1]

Hi,

I know that I can put my debugging inside of the log4j.properties file that Jboss already uses. But I want to use my own file for two reasons:

1. it is more elegant and less confusing to have them separated so that it is less likely to accidentally change the webapps threshold when you wanted to change Jboss's threshold.

2. separate properties files means that the webapps logging does not go into jboss's logs.

[neut6o1]

Sorry I meant to do a longer message but I accidentally posted.

So I have given the reasons why I want separate logging properties. But the strange thing is that I could do this in 2.2.2, there was a log4j.properties file in jboss/conf and when I change that threshold, the jboss logging changes. My kietralog4j.properties file also worked and changed logging for my webapp.

So it seems as if I could do separate properties files in 2.2.2 and there was at least some rudimentary jboss log4j in 2.2.2. This seems to show that there were two log4j configurations in one jvm. Unless in 2.2.2 there was a separate jvm for jboss and the webapp(I highly doubt it).

So I am now thoroughly confused, and if anyone can give more insight into this strange problem it would be much appreciated. Thanks.

Chris Heady

[adrian.brock]

Here is a link to the log4j site where somebody
agrees with you.
They also recommend my solution as the simplest.
No mention of what the complicated ones are :-(

http://jakarta.apache.org/log4j/docs/manual/manual.html#N400858

Looking at CVS you are correct it was in 2.2.2 but
it was commented out in jboss.conf.
i.e. by default jboss used its native logger

Regards,
Adrian

[neut6o1]

Oh, sorry. Yes, thats right, it is by default commented out in 2.2.2, but we uncommented it at one point during installation of log4j. This means that I am allowed to have separate properties files in JBoss 2.2.2. I just checked this with a old version of my webapp. When I change log4j.properties, the jboss logging changes and when I change kietralog4j.properties, my webapps logging changes. Does this mean that somehow a change was made in JBoss to allow only Jboss's log4j.properties?

Chris

[adrian.brock]

You are correct, you can have separate property files.
But only one can control the root category.

I just wrote a simple bean on 3.0 that loaded and
configured its own properties with a category and appender. With the additivity on by default the
messages also got put in the jboss logs.
Here is the start of my property file.
log4j.category.logtest=DEBUG, MyLog

log4j.appender.MyLog=org.apache.log4j.RollingFileAppender
log4j.appender.MyLog.File=../log/logtest.log
etc.
The Log4jService in jboss is hard-wired to control the
root category, re-configuring this would change the
jboss logging.

The code doesn't look to have changed much since
2.2.2 except everything logs directly now instead
of going through the old logger using jmx
notifications (this won't affect config)

Regards,
Adrian

[marc.fleury]

warjort,

methinks the old way of JMX notifications was slightly better as you could plug in your log4j down the road, as you point out this doesn't affect the configuration but I just wanted to get your input on this.

marcf

[adrian.brock]

Hi,

The old JMX notifications gave the ability to do
logging with/without log4j.
But I don't think this solves the configuration problem.

The problem is JBoss controls the root category.
We could just control org.jboss and Default.

At the top of log4j.properties
log4j.category.Default=DEBUG, Console, Default
log4j.category.org.jboss=DEBUG, Console, Default

This works, but you need a small change to
Log4jService which currently retrieves the
root category.

I still haven't figured out why this used to work
in 2.2.2? It controlled the root category there.

Perhaps we should run it by Scott.
From CVS it looks like David Jencks originally
contributed this work.

Incidently, the log4j processing we are using
is deprecated and due to disappear in 2003.

Regards,
Adrian

[neut6o1]

Hello,

I have subscribed to the log4j mailing list. There was a thread that is possibly related to the poblem talked about in this topic. The question is below, and the answer from Ceki Gulcu is below that.

>Hi!
>
>We are coming across a bit of a problem where more and more third party
>libraries and applications are using log4j for their logging. The problem comes
>when JBoss or OpenJMS and third party libraries are all doing their initialisation
>of log4j and we need to as well when we deploy our components.
>
>Have other faced this problem? What are the suggested practices for this?
>
>Thanks.
>
>Aron.

<Ceki Gulcu>
This is a very serious problem. The new log4j API allows the main program to install a RepositorySelector which can control the hierarchy to be used depending on the context, for example depending
on the enterprise application. However, this requires support from the application server because only the application server (e.g. JBoss) controls the context.

In short log4j has the required pluggable interface, the application server writers need to jump on the wagon. I suggest that you mention the problem to the JBoss people also mentioning the new RepositorySelector
API in log4j.

</Ceki Gulcu>

Now this might be talking about different contexts and if your web-application is using the same context as your Jboss server, this might not work.

[adrian.brock]

Ok,

I'll jump on this wagon :-)

Without having investigated this yet, my guess is there
will be a "jboss" context and a "user" or "myapp"
context.

Regards,
Adrian

[adrian.brock]

Yep,

If JBoss calls setRepositorySelector() on the
LogManger with our own RepositorySelector,
we can control which LoggerRepository gets used.

There will be one for JBoss and perhaps one for
each application. Although I think this should made
configurable somewhere.
e.g. All applications logging to one repository
is one option or even sharing the JBoss repository
(which will probably be the default).

More investigation required :-)

Regards,
Adrian

[adrian.brock]

One problem :-(

This is only in log4j 1.2 which is still alpha.

I'm still going to investigate it. I'll
have a go at implementing it, but it probably won't
make it into 3.0????

Regards,
Adrian

[adrian.brock]

I'm waiting for other peoples input on this, to make
sure I understand this correctly.

But it should be possible to produce a simple patch
to JBoss3.0 if you want to run this with log4j 1.2
before it goes final.

I've got some work to do on the JBoss code to prepare
it for log4j 1.2, but I can do that without 1.2

I currently see this working as a container interceptor. e.g. In either standardjboss.xml
or the jboss.xml in your app add the line

org.jboss.logging.UserRepository

where ... is the location of the jndi properties.

This would have the effect of running the application
using totally different configuration to JBoss.

I'm open to ideas on the exact form of the configuration, the above is just an idea.
The use of an xml attribute isn't very standard for
interceptors within jboss.

The interceptor is good because it means extra work
(although in practice virtually nothing) is not done for
apps that don't require this feature. They don't
add it to their configuration.

Regards,
Adrian