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
