7 Replies Latest reply on Jun 13, 2013 3:59 PM by Andrey Polozov

    Migration from AS 5: Logging

    Andrey Polozov Newbie

      (Spin off from Per deployment logging configuration in JBoss AS 7.1.3)


      So, I'm trying to migrate our system from AS 5.2 to EAP 6.1 (AS 7.2.0), or EAP 6.0.1 (AS 7.1.3).

      We have several WAR files deployed separately (no EAR). All web apps use java.utill.logging.Logger for logging. The logger name tied to the full class name:


      private static final Logger logger = Logger.getLogger(TheClass.class.getName());


      Applications share some common classes.


      We need each application to log all messages (from app-specific classes, common and system classes) to a separate file.


      In AS 5 we do this by having a record like this in conf/jboss-log4j.xml for each app:

         <appender name="SomeAppLog" class="org.apache.log4j.DailyRollingFileAppender">

            <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>

            <param name="Append" value="true"/>

            <param name="File" value="${jboss.server.log.dir}/some-app.log"/>

            <param name="DatePattern" value="'.'yyyy-MM-dd"/>

            <param name="Threshold" value="${log4j.threshold.default}" />

             <layout class="org.apache.log4j.PatternLayout">

               <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>


            <filter class="org.jboss.logging.filter.TCLMCFilter">

               <param name="AcceptOnMatch" value="true"/>

               <param name="DeployURL" value="some-app"/>


            <filter class="org.apache.log4j.varia.DenyAllFilter"></filter>



      Then we add those appenders to <root>,  filter out deployments starting with "some-":


         <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">


            <filter class="org.jboss.logging.filter.TCLMCFilter">

               <param name="AcceptOnMatch" value="false"/>

               <param name="DeployURL" value="some-"/>



      That's the current situation.

      Now, according to https://issues.jboss.org/browse/AS7-514 (link from comments), we're supposed to use per-deployment logging config:



      I tried following that recommendation. Here is what I'm getting so far.

      First - I've found some sample of logging.properties file:
















      formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n


      First of all - adding putting that file to WEB-INF or META-INF, as the documentation suggests, doesn't seem to have any affect.

      It looks like it gets picked up only from the classpath (WEB-INF/classes/).

      With that in right place the log does get created, but nothing gets logged there...


      I'll try to experiment with Log4j next...


      I will greatly appreciate any thoughts and ideas regarding this migration.

        • 1. Re: Migration from AS 5: Logging
          Andrey Polozov Newbie


          It looks like the in logging.properties I missed




          That's why it couldn't find the handler apparently... I hope I'm getting closer to the resolution...

          • 2. Re: Migration from AS 5: Logging
            James Perkins Master

            Putting the file in META-INF should work, I'm not sure why it wouldn't work. I updated the documentation too to indicate it should be WEB-INF/classes too and not just WEB-INF. Though maybe both should be allowed. I can't remember why I only did META-INF and WEB-INF/classes now.


            When you say "common" classes, do you mean a shared module or a library that each WAR includes? There is no way to get system level, e.g. JPA, into those. The system modules use the configuration from the standalone.xml.



            James R. Perkins

            • 3. Re: Migration from AS 5: Logging
              Andrey Polozov Newbie

              Thanks James!


              That's right, META-INF works as well as WEB-INF/classes.


              "Common" classes are just some classes that get loaded into all web apps (jars in WEB-INF/lib/ or classes in WEB-INF/classes/)

              The only reason I mentioned those classes is to point that I can't split logs based on logger (package) name.


              Now, with corrected jboss.loggiing I have successfully splitted log files. That part works fine under EAP 6.1.

              (By the way, under EAP 6.0.1 i works... strange: files do get created, but messages in them get mixed up really badly! I couldn't find the pattern in which file it chooses for particular messages)


              My next frontier is setting separate log levels.

              Let's say I want to set default level to INFO, make jacorb less chatty (WARN) and bump the app level up to FINEST.

              So, I do something like this:








              I also set


              to control log level on the logger(category?) level only.


              But I still see DEBUG messages from jacorb, TRACE from org.jboss.jca.core.connectionmanager.listener, etc.

              Any idea why my settings are ignored?

              What's the path of choosing the level for particular logger?

              • 4. Re: Migration from AS 5: Logging
                James Perkins Master

                There was a bug in EAP 6.0.x where the first deployment that accessed a shared class then it would be configured according to that deployments logging configuration. In EAP 6.1 shared resources should be configured at the system log configuration level.


                You defined jacorb as a logger, but you didn't set it's level which would default to ALL. So your configuration should probably look more like:

                # Define loggers
                # Assign handlers to root logger
                # Assign level to root logger
                # Define other loggers



                If you're going to use EAP 6.1 you could have a look at the logging-profiles. This would allow you to do something like the per-deployment logging, but give you the ability to make changes at runtime to the configuration.



                James R. Perkins

                • 5. Re: Migration from AS 5: Logging
                  Andrey Polozov Newbie

                  Jason, it looks like you answered my next question: how to we change logging level on fly?

                  In AS 5 all loggers are configured in common class loader. Apparently per-app logging creates loggers in application's local class loader...

                  So, Logging Profiles is the way.


                  But honestly, when I read the documentation about profiles - I feel dumb and worthless.

                  It says "a logging profile defined on /subsystem=logging/logging-profile=ejbs the MANIFEST.MF would look like..."

                  What does that path mean?

                  Should I put something under logging subsystem in standard.xml?

                  Is there more detailed documentation beside those 5 lines?



                  • 6. Re: Migration from AS 5: Logging
                    James Perkins Master

                    Good feedback Andrey. Documentation is clearly not my strong point .


                    The path is what you would use in CLI to define a logging profile. In CLI you would enter something like /subsystem=logging/logging-profile=ejbs:add to create the profile. From there it's you could execute any other logging commands/operations to that profile path, e.g. /subsystem=logging/logging-profile=ejbs/root-logger=ROOT:add.


                    You can edit the raw XML, but I would suggest using CLI to add profiles.



                    James R. Perkins

                    • 7. Re: Migration from AS 5: Logging
                      Andrey Polozov Newbie

                      OK, I have deduced the structure of logging profiles from XML Schema (docs/schema/jboss-as-logging_1_2.xsd) Documentation is for sissies! 8-)

                      Now I have full functionality of TCLMCFilter implemented via logging profiles!

                      Thanks again James!

                      I'll have to put the logging aside for a while, because now I need to fix ws-security (again). I'll open separate topic for that...