So do u want me to check the current patch of OPENEJB-601 or you are going
to submit a cumulative patch ???
On 6/21/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
>
> 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
>
--
Thanks
- Mohammad Nour
