You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2007/06/20 03:38:56 UTC
Ever-changing maven log levels
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
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
Thanks,
I was just looking into that class.
On 6/20/07, David Blevins <da...@visi.com> wrote:
>
> On Jun 19, 2007, at 8:37 PM, Karan Malhi wrote:
>
> > I would love to work on this issue. I dont see a JIRA created for this
> > one though. PropertyConfigurator class is useful information for me to
> > start looking into stuff.
> >
> > David also mentioned that we use java.util.Logging instead of log4j.
> > How easy is it to port openejb to java.util.Logging?
>
> Should be easy as all our log4j usage is encapsulated in the
> org.apache.openejb.util.Logger class. We'd just need to rewrite that
> class to wrap java.util.Logging instead.
>
> -David
>
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by David Blevins <da...@visi.com>.
On Jun 19, 2007, at 8:37 PM, Karan Malhi wrote:
> I would love to work on this issue. I dont see a JIRA created for this
> one though. PropertyConfigurator class is useful information for me to
> start looking into stuff.
>
> David also mentioned that we use java.util.Logging instead of log4j.
> How easy is it to port openejb to java.util.Logging?
Should be easy as all our log4j usage is encapsulated in the
org.apache.openejb.util.Logger class. We'd just need to rewrite that
class to wrap java.util.Logging instead.
-David
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
I would love to work on this issue. I dont see a JIRA created for this
one though. PropertyConfigurator class is useful information for me to
start looking into stuff.
David also mentioned that we use java.util.Logging instead of log4j.
How easy is it to port openejb to java.util.Logging?
On 6/19/07, Mohammad Nour El-Din <no...@gmail.com> 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.xml configuration 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 :-)
>
> On 6/20/07, Karan Malhi <ka...@gmail.com> 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 <da...@visi.com> 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
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
Sorry,
I really didnt answer your question. I want to first try and fix this
problem with log4j. Seems like I am close to getting it fixed fully by
changing the logger a bit. If I cannot fix with log4j, then I will
look into java.util.logging
On 6/20/07, Karan Malhi <ka...@gmail.com> wrote:
> This is just an interim fix. Just so that you can see the logging
> output and fix any build errors in future. I am still working on it
> and trying to find the root cause of why surefire is not picking up
> the logging.conf files initially , but picks em up later during the
> testing phase.
>
> On 6/20/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
> > Karan, I will look at your patch, but just a stupid question, we are talking
> > here about Java logging APIs or Log4j cauz AFAIU u talked about both :-)
> >
> > On 6/21/07, Karan Malhi <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > > > On 6/20/07, David Blevins <da...@visi.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
> > >
> >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
> >
>
>
> --
> Karan Malhi
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
This is just an interim fix. Just so that you can see the logging
output and fix any build errors in future. I am still working on it
and trying to find the root cause of why surefire is not picking up
the logging.conf files initially , but picks em up later during the
testing phase.
On 6/20/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
> Karan, I will look at your patch, but just a stupid question, we are talking
> here about Java logging APIs or Log4j cauz AFAIU u talked about both :-)
>
> On 6/21/07, Karan Malhi <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > > On 6/20/07, David Blevins <da...@visi.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Karan, I will look at your patch, but just a stupid question, we are talking
here about Java logging APIs or Log4j cauz AFAIU u talked about both :-)
On 6/21/07, Karan Malhi <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > On 6/20/07, David Blevins <da...@visi.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
>
--
Thanks
- Mohammad Nour
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
Mohammad,
I submitted a cumulative patch.
On 6/21/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
> 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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > > > On 6/20/07, David Blevins <da...@visi.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by Mohammad Nour El-Din <no...@gmail.com>.
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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > > On 6/20/07, David Blevins <da...@visi.com> 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
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 <ka...@gmail.com> 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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > > On 6/20/07, David Blevins <da...@visi.com> 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.xml configuration
> > > > > 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
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 <ka...@gmail.com> 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 <no...@gmail.com> wrote:
> > On 6/20/07, David Blevins <da...@visi.com> 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.xml configuration
> > > > 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
David,
You are right. I looked into it further, for the OpenEJB.startup
category we have three ConsoleAppender instances. For the rest of the
categories, there is just one appender.
I have not been able to figure out why this is happening only for the
OpenEJB.startup category
On 6/26/07, Karan Malhi <ka...@gmail.com> wrote:
> I noticed that too. Initially it did duplicate or triplicate messages
> because of the parent child relationship you mentioned. That is why i
> set additivity to false.
>
> I was also still getting messages duplicated , but when i looked
> through the tests, sometimes the log.info calls were made within some
> code which was looping, hence was logging the same message again and
> again.
>
> Now If you set additivity to false in the doFallbackConfiguration()
> also, then it might take care of duplicacy for the rest of the
> loggers.
>
> Some of the loggers are also obtained from default.logging.conf. But
> the conf file does not set additivity to false.
>
> So, just bear with this duplicacy a little bit till i fully fix it.
>
> On 6/26/07, David Blevins <da...@visi.com> wrote:
> > With the cumulative.patch on OPENEJB-601, we're getting triple log
> > messages sometimes. It doesn't happen on all categories.
> >
> > I haven't looked, but I wonder if something like this is happening:
> >
> > Class Foo asks for "OpenEJB.startup", we add an appender and cache
> > Class Bar asks for "OpenEJB.startup.validation", we add an appender
> > and cache
> >
> > The end result is that there are two appenders, one on "validation"
> > directly and on inherited from "startup", and possibly a third
> > inherited from "OpenEJB"
> >
> > But as I say, I haven't looked it just occurred to me based on the
> > fact that only some log messages repeat and some don't.
> >
> > -David
> >
> >
>
>
> --
> Karan Malhi
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
I noticed that too. Initially it did duplicate or triplicate messages
because of the parent child relationship you mentioned. That is why i
set additivity to false.
I was also still getting messages duplicated , but when i looked
through the tests, sometimes the log.info calls were made within some
code which was looping, hence was logging the same message again and
again.
Now If you set additivity to false in the doFallbackConfiguration()
also, then it might take care of duplicacy for the rest of the
loggers.
Some of the loggers are also obtained from default.logging.conf. But
the conf file does not set additivity to false.
So, just bear with this duplicacy a little bit till i fully fix it.
On 6/26/07, David Blevins <da...@visi.com> wrote:
> With the cumulative.patch on OPENEJB-601, we're getting triple log
> messages sometimes. It doesn't happen on all categories.
>
> I haven't looked, but I wonder if something like this is happening:
>
> Class Foo asks for "OpenEJB.startup", we add an appender and cache
> Class Bar asks for "OpenEJB.startup.validation", we add an appender
> and cache
>
> The end result is that there are two appenders, one on "validation"
> directly and on inherited from "startup", and possibly a third
> inherited from "OpenEJB"
>
> But as I say, I haven't looked it just occurred to me based on the
> fact that only some log messages repeat and some don't.
>
> -David
>
>
--
Karan Malhi
Re: Ever-changing maven log levels
Posted by David Blevins <da...@visi.com>.
With the cumulative.patch on OPENEJB-601, we're getting triple log
messages sometimes. It doesn't happen on all categories.
I haven't looked, but I wonder if something like this is happening:
Class Foo asks for "OpenEJB.startup", we add an appender and cache
Class Bar asks for "OpenEJB.startup.validation", we add an appender
and cache
The end result is that there are two appenders, one on "validation"
directly and on inherited from "startup", and possibly a third
inherited from "OpenEJB"
But as I say, I haven't looked it just occurred to me based on the
fact that only some log messages repeat and some don't.
-David
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
> We shouldn't have any code that doesn't derive from the "OpenEJB."
> category. If we do, we need to fix it.
I will probably add it as one of the rules of logging in OpenEJB
> I'm not sure I understand surefire's involvement here.
surefire sets up the log4j.configuration property. The
Log4jConfigUtils tries to use this property .So right now, I dont know
of any other way we will be able to set this property before a
Logger is used except for asking surefire to set it.
>Is it possible for us to setup the logging for our categories and ignore
> the need for users (us too) to play nice with surefire?
I think we already have that in the Logger where it is wrapping log4j
loggers without depending on the log4j.configuration property . But we
lose out on the ability to configure each logger and its appender.
Well, maybe we could use the ConfUtils here and look for the file in a
specific location, if not found then set the defaults and use it.
Somewhat like the doFallbackConfiguration()
Re: Ever-changing maven log levels
Posted by David Blevins <da...@visi.com>.
On Jun 20, 2007, at 2:05 PM, Karan Malhi wrote:
> 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.
Thanks. I know I did something similar at least once before (http://
svn.apache.org/viewvc?view=rev&revision=497690).
> 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)
Me either.
> - 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.
We shouldn't have any code that doesn't derive from the "OpenEJB."
category. If we do, we need to fix it.
> - 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)
The server/openejb-client module uses java.util.Logging as it's
forbidden to have any deps at all (sans spec jars) in that package.
It doesn't even have a dep on openejb-core or openejb-server. Sort
of another reason why using java.util.Logging in the server side
would be desirable -- one less dep there and all code using the same
logging framework.
> - 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
I'm not sure I understand surefire's involvement here. Is it
possible for us to setup the logging for our categories and ignore
the need for users (us too) to play nice with surefire?
> - 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).
I seem to vaguely recall that was left over from very early in the 3x
development cycle when we couldn't get logging to work unless the
file as on disk in a directory called conf/. Agreed, we definitely
want to get rid of that cruft.
> - 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
This is fine except for maybe the examples/ modules where what we do
there is what we expect (require) users to do. Ideally, surefire
would have no part in any of this as all the embedded testing stuff
should work in IDEs, ant, tomcat, maven1 or any other embedded
environment.
> 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.
Hopefully the info in the "Logging Strategy -- help" addresses what
you're mentioning here.
-David
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
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 <no...@gmail.com> wrote:
> On 6/20/07, David Blevins <da...@visi.com> 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.xml configuration
> > > 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 6/20/07, David Blevins <da...@visi.com> 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.xml configuration
> > 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 <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by David Blevins <da...@visi.com>.
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.xml configuration
> 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
>
> On 6/20/07, Karan Malhi <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by Mohammad Nour El-Din <no...@gmail.com>.
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.xml configuration 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 :-)
On 6/20/07, Karan Malhi <ka...@gmail.com> 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 <da...@visi.com> 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
Re: Ever-changing maven log levels
Posted by David Blevins <da...@visi.com>.
On Jun 19, 2007, at 7:29 PM, Karan Malhi 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 :)
Cool! If only my tech vocabulary in Spanish wasn't so terrible I
could help there :)
> 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.
Right, I definitely think nailing down the plugin versions will help
stabilize our build.
But as far as logging goes we still need to find a way to yank
control from maven as we still have everyone else's build to worry
about who will use OpenEJB to embedded test their ejbs. We need an
absolute guarantee that when we say "this didn't work" they get that
message.
> 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?
Pretty much. Each test gets it's own "OpenEJB" already, should be
fine to throw in some info as to what they want the log levels to be
in addition to the other options they can already set via properties
passed into the LocalInitialContextFactory.
-David
>
>
> On 6/19/07, David Blevins <da...@visi.com> 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
>
Re: Ever-changing maven log levels
Posted by Karan Malhi <ka...@gmail.com>.
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 <da...@visi.com> 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