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 <[EMAIL PROTECTED]> 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 <[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
-- Karan Malhi
