Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 2.1.0
    • Fix Version/s: None
    • Component/s: docs
    • Labels:
    • Environment:
      n/a

      Description

      The manual does not clearly give guidance on how to setup java.util.logging, including some of the pitfalls likely to be encountered.

      I will be submitting a patch for the docs.

        Activity

        Hide
        Jason Pyeron added a comment -

        mailing list post:
        > ----Original Message----
        > From: Michael Dick
        > Sent: Wednesday, July 13, 2011 14:46
        > Subject: Re: Logging questions
        >
        > On Wed, Jul 13, 2011 at 12:00 PM, Jason Pyeron
        > wrote:
        >
        > > > ----Original Message----
        > > > From: Michael Dick
        > > > Sent: Wednesday, July 13, 2011 12:53
        > > > Subject: Re: Logging questions
        > > >
        > > > It looks like you have the log4j-over-slf4j bridge on your
        > > > classpath. Or some combination of the different logging
        > facilities.
        > >
        > > It is possible. But my test case does not have it. I will
        > check deeper
        > > on this.
        >
        >
        > FWIW, I created a maven project with just commons-logging and
        > log4j-over-slf4j on the classpath, and got a very similar error. It
        > sounds like you have a standalone testcase too, is that something you
        > can send us?
        >

        Will have to work it up clean, as it uses our local db. But that may be moot, see below.

        >
        > > >
        > > > So commons-logging detects log4j and tries to use it.
        > Log4j tries to
        > > > delegate to slf4j, but that fails due to the missing
        > implementation
        > > > class.
        > > >
        > > > Do other parts of your application use log4j or slf4j? If
        > not, can
        > > > you remove them from the classpath and try 'just'
        > > > with commons-logging?
        > > >
        > >
        > > There are legacy parts of the system that were designed for other
        > > logging frameworks, I do not have permission to modify
        > those. I will
        > > need to find a way to force java.util.logging.
        >
        >
        > I think this is more of a commons-logging behavior than OpenJPA. From
        > looking at the commons-logging
        > documentation<http://commons.apache.org/logging/commons-loggin
        g-1.1.1/guide.html#Configuration>it
        > will look for log4j on the classpath before trying java.util.logging.
        >
        > The doc doesn't spell it out, or at least I couldn't find it, but you
        > can add a commons-logging.properties file to the classpath. The
        > properties file should have this entry :
        > org.apache.commons.logging.Log=org.apache.commons.logging.impl
        > .Jdk14Logger
        >

        Bingo. It is a commons-logging issue. I will open a jira ticket up and submit a patch (over the weekend) to update the docs for openjpa adding this example.

        > In my simple test it looks like it used Jdk4Logging. I don't know
        > whether it will play well with the legacy parts of your system, but
        > it's worth a try.
        >
        > Hope this helps,
        > -mike
        >
        > <snip>
        >

        Show
        Jason Pyeron added a comment - mailing list post: > ---- Original Message ---- > From: Michael Dick > Sent: Wednesday, July 13, 2011 14:46 > Subject: Re: Logging questions > > On Wed, Jul 13, 2011 at 12:00 PM, Jason Pyeron > wrote: > > > > ---- Original Message ---- > > > From: Michael Dick > > > Sent: Wednesday, July 13, 2011 12:53 > > > Subject: Re: Logging questions > > > > > > It looks like you have the log4j-over-slf4j bridge on your > > > classpath. Or some combination of the different logging > facilities. > > > > It is possible. But my test case does not have it. I will > check deeper > > on this. > > > FWIW, I created a maven project with just commons-logging and > log4j-over-slf4j on the classpath, and got a very similar error. It > sounds like you have a standalone testcase too, is that something you > can send us? > Will have to work it up clean, as it uses our local db. But that may be moot, see below. > > > > > > > So commons-logging detects log4j and tries to use it. > Log4j tries to > > > delegate to slf4j, but that fails due to the missing > implementation > > > class. > > > > > > Do other parts of your application use log4j or slf4j? If > not, can > > > you remove them from the classpath and try 'just' > > > with commons-logging? > > > > > > > There are legacy parts of the system that were designed for other > > logging frameworks, I do not have permission to modify > those. I will > > need to find a way to force java.util.logging. > > > I think this is more of a commons-logging behavior than OpenJPA. From > looking at the commons-logging > documentation< http://commons.apache.org/logging/commons-loggin g-1.1.1/guide.html#Configuration>it > will look for log4j on the classpath before trying java.util.logging. > > The doc doesn't spell it out, or at least I couldn't find it, but you > can add a commons-logging.properties file to the classpath. The > properties file should have this entry : > org.apache.commons.logging.Log=org.apache.commons.logging.impl > .Jdk14Logger > Bingo. It is a commons-logging issue. I will open a jira ticket up and submit a patch (over the weekend) to update the docs for openjpa adding this example. > In my simple test it looks like it used Jdk4Logging. I don't know > whether it will play well with the legacy parts of your system, but > it's worth a try. > > Hope this helps, > -mike > > <snip> >
        Jason Pyeron created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Jason Pyeron
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development