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