Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.1peur2
    • Fix Version/s: not determined
    • Component/s: logging
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      6,666

      Description

      I'm trying to get Glassfish to log to slf4j instead of Java Logging but I've run
      into a dead end: http://forums.java.net/jive/thread.jspa?threadID=52441&tstart=30

      It would be great if the Glassfish logging mechanism was plugable or at the very
      least if I could somehow get access to the original System.out object to pass
      into slf4j.

        Activity

        Hide
        niklash added a comment -
            • Issue 6666 has been confirmed by votes. ***
        Show
        niklash added a comment - Issue 6666 has been confirmed by votes. ***
        Hide
        cowwoc added a comment -

        Can someone from the Glassfish team please comment on this issue?

        Show
        cowwoc added a comment - Can someone from the Glassfish team please comment on this issue?
        Hide
        cowwoc added a comment -

        http://hwellmann.blogspot.com/2010/12/glassfish-logging-with-slf4j-part-2.html contains a workaround for redirecting all Glassfish logs onto slf4j. I'm still looking for a way to redirect on a per-webapp basis.

        Show
        cowwoc added a comment - http://hwellmann.blogspot.com/2010/12/glassfish-logging-with-slf4j-part-2.html contains a workaround for redirecting all Glassfish logs onto slf4j. I'm still looking for a way to redirect on a per-webapp basis.
        Hide
        cinhtau added a comment -

        Per webapp basis you have to put an independent logback.xml and invoke JoranConfigurator directly. That's the trick. See http://logback.qos.ch/manual/configuration.html

        Show
        cinhtau added a comment - Per webapp basis you have to put an independent logback.xml and invoke JoranConfigurator directly. That's the trick. See http://logback.qos.ch/manual/configuration.html
        Hide
        cowwoc added a comment -

        I understand, but you're still requiring me to place slf4j libraries in the global location and hook all java.util.logging instances to slf4j whether they want it or not.

        Show
        cowwoc added a comment - I understand, but you're still requiring me to place slf4j libraries in the global location and hook all java.util.logging instances to slf4j whether they want it or not.
        Hide
        orair added a comment -

        If the logging libraries are on a shared place, configure Glassfish per webapp basis will probably need to create contexts. See http://logback.qos.ch/manual/loggingSeparation.html#ContextJNDISelector for more information.

        Show
        orair added a comment - If the logging libraries are on a shared place, configure Glassfish per webapp basis will probably need to create contexts. See http://logback.qos.ch/manual/loggingSeparation.html#ContextJNDISelector for more information.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Hide
        cowwoc added a comment -

        I ended up redirecting slf4j to java.util.logging (JUL). To do this simply use slf4j-jdk14 as your logger implementation in place of logback. Unfortunately, this trades off one problem for another.

        On the one hand, your logging is unified. On the other hand, you inherit all the problems associated with JUL. You cannot use any logback-specific features. You cannot use logback.xml to configure your logging. In fact, you cannot even configure different logging rules per webapp (see GLASSFISH-18776). I ended up with the following code in my ServletContextListener:

        @Override
        public void contextInitialized(ServletContextEvent servletContextEvent)
        {
          super.contextInitialized(servletContextEvent);
        
          // WORKAROUND: http://java.net/jira/browse/GLASSFISH-18776
          java.util.logging.Logger.getLogger("com.foo.bar").setLevel(Level.ALL);
        }
        

        It doesn't solve the problem of all webapps sharing the same logging configuration, but at least now the configuration is packaged in the webapp itself (as opposed to logging.properties in Glassfish's installation directory).

        Show
        cowwoc added a comment - I ended up redirecting slf4j to java.util.logging (JUL). To do this simply use slf4j-jdk14 as your logger implementation in place of logback. Unfortunately, this trades off one problem for another. On the one hand, your logging is unified. On the other hand, you inherit all the problems associated with JUL. You cannot use any logback-specific features. You cannot use logback.xml to configure your logging. In fact, you cannot even configure different logging rules per webapp (see GLASSFISH-18776 ). I ended up with the following code in my ServletContextListener: @Override public void contextInitialized(ServletContextEvent servletContextEvent) { super .contextInitialized(servletContextEvent); // WORKAROUND: http://java.net/jira/browse/GLASSFISH-18776 java.util.logging.Logger.getLogger( "com.foo.bar" ).setLevel(Level.ALL); } It doesn't solve the problem of all webapps sharing the same logging configuration, but at least now the configuration is packaged in the webapp itself (as opposed to logging.properties in Glassfish's installation directory).
        Hide
        jthoennes added a comment -

        We managed to deploy SLF4J as an OSGi bundle. So you can deploy it in the normal way instead of in the lib directory.
        And the configuration could be done in the bundle activator.

        Show
        jthoennes added a comment - We managed to deploy SLF4J as an OSGi bundle. So you can deploy it in the normal way instead of in the lib directory. And the configuration could be done in the bundle activator.

          People

          • Assignee:
            naman_mehta
            Reporter:
            cowwoc
          • Votes:
            24 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: