I have figured out why log messages are printed more than once. I had
to set the additivity of the logger to false. Will fix this and submit
a patch later
On 6/20/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
> You might see the same log message displayed more than once. Looked at
> Logger again, Some of the loggers are having more than one
> ConsoleAppender attached to them. If somebody can tell me what is
> wrong with the fix I provided in Logger.getInstance(), that would be
> cool.
>
> On 6/20/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
> > I initially thought surefire is the culprit. The problem is two fold
> > 1. surefire plugin is not configured correctly to set the
> > log4j.configuration property for the module
> > 2.Surefire is partially the culprit, but the main thing affecting
> > logging is Logger.java. Here is why
> > If we run the tests in openejb-core, the first test to run is
> > org.apache.openejb.core.stateless.JaxWsWebServiceInvocationTest
> > In this test, we create a new ConfigurationFactory instance.
> > A ConfigurationFactory instance gets a handle to a logger as shown
below:
> > private static final Logger logger =
> > Logger.getInstance("OpenEJB.startup.config",
> > "org.apache.openejb.util.resources");
> >
> > The Logger then looks into its HashMap to find a Category, if it
> > cannot find one (which it cannot since this is the first invocation),
> > it creates a Logger instance and adds it to the HashMap. The problem
> > is when it creates a Logger, it does not add an appender to it, hence
> > the log4j:WARN no appenders found for logger OpenEJB.startup.config).
> > So, I did a dirty hack by appending a ConsoleAppender with a
> > SimpleLayout. Not the ideal solution, but atleast you get to see the
> > log output to fix the current build issue.
> >
> > Please apply the patch in OpenEJB-601
> >
> > This should atleast get you started with getting the logging output
> >
> >
> > I am still in the process of understanding the Logging process. I
> > would like to mention a few things here though. (I need some help here
> > cos I am not a log4j expert)
> >
> > - At some places in the code, we are using loggers which are not
> > defined in the default.logging.conf for that module, hence no
> > appenders, hence no output. I have worked around this problem with a
> > small hack in Logger.java.
> > - There are some tests which do not use a logger at all, hence no
> > output for them either
> > - Some pieces of code are using java.util.logging directly. I dont
> > know if we can tie log4j to the logging system in java.util.logging,
> > but this seems to bypass log4j completely (I guess)
> > - There are some places where we are using System.out.print statements
> > , whereas we couldve used a logger instead.
> > - the surefire plugin needs to be told where the log4j.configuration
> > property points to. Seems like we are doing this only for the ejb-core
> > module. I think this property for surefire should be configured in the
> > parent pom itself. This is because its only the tests in openejb-core
> > which will produce any log output, for the rest of the tests, surefire
> > would not even know where the logging conf file is because we never
> > told it where it was
> > - each module has its own default.logging.conf file (i havent seen all
> > modules, but did notice in some). I think logging should be universal
> > and there should be just one default.logging.conf file in the
> > root/parent module. This will lead to a simpler configuration of
> > logging (although it might be less flexible).
> > - surefire plugin is not versioned. I think version 2.3 has some
> > classloading issues, I would recommend to switch to version 2.2 and
> > then work on logging stuff , make logging stable and then if required
> > move to 2.3
> >
> > I think Logger.java needs to basically find the default.logging.conf
> > for the module the tests are running for and then cache all
> > org.apache.log4j.Logger instances along with their appenders and
> > layouts. This should be done one time only in getInstance method.
> > Please let me know your thoughts on this solution.
> >
> >
> >
> > On 6/20/07, Mohammad Nour El-Din <[EMAIL PROTECTED]> wrote:
> > > On 6/20/07, David Blevins <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > On Jun 19, 2007, at 8:26 PM, Mohammad Nour El-Din wrote:
> > > >
> > > > > Well I am not sure if that would help or not, but lately I was
> > > > > reading the
> > > > > "Log4j Complete manual", and knew some new stuff about Log4j,
and I
> > > > > couldn't
> > > > > find any log4j.properties or even there new log4j.xmlconfiguration
> > > > > files,
> > > > > all what I found is that at some place in our code - which I
can't
> > > > > remember
> > > > > right now - configures log4j using its PropertyConfigurator
class,
> > > > > which I
> > > > > think makes us have less control on logging using log4j, I wish
I
> > > > > could help
> > > > > in this area but I already have a lot of things do here, but I
> > > > > think I can
> > > > > help someone in that if I have time, Karan what do you think of
> > > > > taking care
> > > > > of this :-) ??? I think as David said it is a good start for
> > > > > contributing to
> > > > > OpenEJB :-)
> > > >
> > > > Yea, the issue with log4j is that someone can easily come around
> > > > later and undo all your work by adding their own log4j.properties
> > > > (even a dep you include in your classpath can affect things this
way)
> > > > and you ultimately get a completely unpredictable logging system.
> > > >
> > > > I'm not a log4j guru, so maybe there is some way to ensure your
log
> > > > categories remain untouched regardless of who might be messing
with
> > > > the root category all things inherit from. Dunno. Even so, if we
> > > > can get logging without the extra dependency, it might be a good
idea.
> > > >
> > > > -David
> > >
> > >
> > > Well, as far as I read into the manual I see that each logger can
take full
> > > control, and it can override the configurations of the rool logger
easily.
> > > And about putting a lot of log4j.properties or log4j.xml files, I
think this
> > > will not work properly, cause the initialization of log4j happens
only ones
> > > when the first logger is instantiated, so we can configure a logger,
lets
> > > call it the main OpenEJB looger with name *org.apache.openejb*,
configure
> > > with whatever configuration we want common to all OpenEJB packages
and then
> > > we can create other loggers which inhirit from this one, and we can
control
> > > which appenders we want to attache to this logger, and even we can
de-attach
> > > the appenders of the rool logger to from this one, so we have no
relation
> > > with the root logger or anybody plays with it, sure it needs
somework and
> > > investigation, this is y I said I can help someone with that. It
seems that
> > > Karan is our hero :-) in this matter.
> > >
> > > >
> > > > > On 6/20/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
> > > > >>
> > > > >> David,
> > > > >>
> > > > >> We should version our plugins explicitly. This way we dont have
to
> > > > >> worry about a latest plugin messing up the build process. I
myself
> > > > >> went through days of working with maven just to get a some
filtering
> > > > >> to work. Maven users group was also of little help as everybody
was
> > > > >> facing the same issue.
> > > > >>
> > > > >> I also agree on externalizing the messages. Maybe some day I
could
> > > > >> add
> > > > >> some messages in Gurmukhi language :)
> > > > >>
> > > > >> The first thing I can think of is to look at our pom.xml files
and
> > > > >> find any plugin which has not been versioned or tested (I
myself did
> > > > >> not version the maven resources-plugin which I used in my
latest
> > > > >> patch, couldnt do it at that time. Will fix that along with
some
> > > > >> cleanup required for the final build). It would be a real waste
of
> > > > >> time and energy if this logging issue was fixed and some plugin
again
> > > > >> came in and messed it up. Changing versions manually, will
atleast
> > > > >> give an idea as to which plugin caused the problem.
> > > > >>
> > > > >> When you say to configure log levels via test cases, do you
mean a
> > > > >> test case should be able to control its own log level?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 6/19/07, David Blevins <[EMAIL PROTECTED]> wrote:
> > > > >> > So I'm in the process of trying to get our build working
again
> > > > >> -- new
> > > > >> > interceptor tests don't pass -- and it seems in the latest
> > > > >> version of
> > > > >> > maven or one of it's plugins the log levels have changed
*again*
> > > > >> and
> > > > >> > *all* of our log statements are going right into the bit
bucket
> > > > >> (i.e.
> > > > >> > nowhere). Now I'm stuck adding print statements trying to
> > > > >> figure out
> > > > >> > which apps are picking up in the classpath, which beans are
being
> > > > >> > deployed, what their deployment ids are, and what their jndi
names
> > > > >> > are. Users will never be able to stomach that. Meanwhile we
> > > > >> already
> > > > >> > have logging statements for all of these and more, but we
just
> > > > >> can't
> > > > >> > get maven to output anything at build time.
> > > > >> >
> > > > >> > At one point, we were getting zero log info like we have now
and I
> > > > >> > fought with maven for days trying to get it to spit out
anything at
> > > > >> > all and days more to get it to print out just the right
balance of
> > > > >> > messages. And then of course it all stops working again on
some
> > > > >> > random plugin update at a moments notice.
> > > > >> >
> > > > >> > If there's someone out there who wants to take a crack at
saving us
> > > > >> > and our embedded testing users from maven's logging control
that
> > > > >> > would be most excellent. I have some ideas but little
patients to
> > > > >> > spare ... and truth be told (i seem to like that phrase
lately)
> > > > >> there
> > > > >> > is a lot of work in the logging area and it would be
fantastic for
> > > > >> > someone(s) to step and wrestle this beast to the ground.
> > > > >> Certainly a
> > > > >> > very excellent area for contribution.
> > > > >> >
> > > > >> > So some of the ideas:
> > > > >> >
> > > > >> > - Maybe use the vm's util logging instead of log4j.
> > > > >> > 1. Maven controls log4j via commons logging and we
might be
> > > > >> > able to take control back if we used something else.
> > > > >> > 2. Log4j is one extra library we might be able to shave
> > > > >> out of
> > > > >> > our distro size.
> > > > >> >
> > > > >> > - We should be able to set log levels *in a test case*. If
I'm
> > > > >> > trying to debug why a test is failing first thing I'll want
to
> > > > >> do is
> > > > >> > turn the log levels up. We can already configure just about
> > > > >> anything
> > > > >> > via the properties passed into the InitialContextFactory, we
should
> > > > >> > be able to configure that too.
> > > > >> >
> > > > >> > - We have absolutely no docs on how to tweak the logging
and what
> > > > >> > info is available for people for people. We don't need a
complete
> > > > >> > reference, but the very minimum we should have a doc with
some
> > > > >> basic
> > > > >> > advice on how to get more out of the logging statements.
> > > > >> >
> > > > >> > - As always, we have a ton of non-externalized messages
which
> > > > >> need
> > > > >> > to be put into property files. Manu mentioned this one the
> > > > >> other day
> > > > >> > and I totally agree.
> > > > >> >
> > > > >> > - The relationship between where the i18n messages
properties
> > > > >> file
> > > > >> > lives and where the code lives has drifted apart over the
years and
> > > > >> > now pretty much has no discernible relationship at all. We
should
> > > > >> > have a properties file for each package, but we don't.
> > > > >> >
> > > > >> > There's likely more that I can't think of just now.
> > > > >> >
> > > > >> > What do others think and who has any energy they could put
into
> > > > >> > this? And don't forget several forms of contribution are
possible
> > > > >> > (creativity is the only real limit) and you don't need to be
a
> > > > >> > committer to join the fun.
> > > > >> >
> > > > >> > -David
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Karan Malhi
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks
> > > > > - Mohammad Nour
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> > >
> >
> >
> > --
> > Karan Malhi
> >
>
>
> --
> Karan Malhi
>
--
Karan Malhi
