1 2 3 Previous Next 37 Replies Latest reply on Apr 16, 2004 10:59 AM by Lecan

    Separate log4j.properties not allowed?

    Chris Heady Newbie

      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

        • 1. Re: Separate log4j.properties not allowed?
          marc fleury Master

          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,


          • 2. Re: Separate log4j.properties not allowed?
            Adrian Brock Master


            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

            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 :-(


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


            • 3. Re: Separate log4j.properties not allowed?
              Chris Heady Newbie


              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.

              • 4. Re: Separate log4j.properties not allowed?
                Chris Heady Newbie

                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

                • 5. Re: Separate log4j.properties not allowed?
                  Adrian Brock Master

                  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 :-(


                  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


                  • 6. Re: Separate log4j.properties not allowed?
                    Chris Heady Newbie

                    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?


                    • 7. Re: Separate log4j.properties not allowed?
                      Adrian Brock Master

                      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

                      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)


                      • 8. Re: Separate log4j.properties not allowed?
                        marc fleury Master


                        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.


                        • 9. Re: Separate log4j.properties not allowed?
                          Adrian Brock Master


                          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.


                          • 10. Re: Separate log4j.properties not allowed?
                            Chris Heady Newbie


                            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.

                            >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?

                            <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.

                            • 11. Re: Separate log4j.properties not allowed?
                              Adrian Brock Master


                              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"


                              • 12. Re: Separate log4j.properties not allowed?
                                Adrian Brock Master


                                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 :-)


                                • 13. Re: Separate log4j.properties not allowed?
                                  Adrian Brock Master

                                  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????


                                  • 14. Re: Separate log4j.properties not allowed?
                                    Adrian Brock Master

                                    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


                                    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.


                                    1 2 3 Previous Next