Quoting Ceki G�lc� <[EMAIL PROTECTED]>: > At 02:11 AM 11/29/2004, Jacob Kjome wrote: > > >Yep, I actually would have been surprised to have it as the default, > >especially since a JNDI provider is only available under a J2EE container, > >so it wouldn't make sense at all for standalone applications. > > Without JNDI, ContextJNDISelector would *behave* exactly as the current > DefaultSelector, at least in terms of the returned repository. Of course, > it would do so much slower than the DefaultSelector. Anyway, your point is > well taken. >
Maybe if no provider is found the first time it would skip the JNDI lookup all other times, making the performance deficit inconsequential. > [cut] > > >You miss the point on this comment. The error happens, but not because of > >a clash with the ContextJNDISelector. It has to be something else, but > >I'm not sure what it is. I actually made a version of the sandbox jar > >that is 1.3 compatible so that I could still use my initializer code. I > >think the problem happens when I attempt to set the repository selector > >(the 1.3 one). I'm not quite sure about this, though. I have to do more > >investigation. > > OK, I'll wait for the results of your investigation. > I don't have much time right now, but there is definitely something bad going on if one calls LogManager.setRepositorySelector() to set the selector. I get the stack trace where the Log4j hits a null pointer in LogManager constantly. More later tonight (I hope). > [cut] > > > >Would you like to fix this by adding and using a new method, say > > >Loader.getResourceByTCLOnly() or should I? > > > > > > >I understand what you are trying to say. However, I think the premise is > >false. To assume that using the thread context classloader will avoid > >loading resources from, say..., Tomcat's common/classes is just > >incorrect. You are right that preference will be given to the resource in > >WEB-INF/classes. However, if that is not found, normal Java2 classloading > >behavior resumes and a log4j.xml file in common/classes would, in fact, be > >found and utilized. I can't imagine what your proposed > >Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a > >solvable problem. The only solution I can see is to perform > >initialization on non-default repositories if, and only if, the > >configuration was provided via the "log4j/configuration-resource" JNDI > >entry and not fall back to loading off the classloader. In this case, > >applications would need to perform manual configuration. An alternative > >to this is to keep the current behavior or falling back to the classloader > >to find the config file and tell users that actually want to perform > >manual configuration (for whatever reason) to put a minimal config file in > >WEB-INF/classes to pacify autoconfiguration and then perform the manual > >configuration that they so desire. > > > >Thoughts? > > Still digesting... > > > > >>However, it seems that having the "debug" attribute there at all, > > >>regardless of the value, triggers debugging. I verified this by removing > > >>the attribute altogether and the Joran parsing logging went away. I > think > > >>this is a bug, although I'm not sure exactly where to fix it? > > > > > >No, it's supposed to be a feature. :-) > > > > > > >Well, it is a confusing feature. I don't expect debug="false" to turn on > >internal debugging. This behavior seems reminiscent of boolean attributes > >in HTML such as "checked" which for XHTML turns into > >checked="checked". Of course that's simply a hack to keep compatibility > >between HTML and XHTML. I'm not sure why we'd want to purposefully > >introduce an XML hack into a Log4j config file? Is it hard using > >JoranConfigurator to distinguish debug="true" and debug="false" and having > >the absence of the debug attribute mean debug="false". This would be > >important to be as compatible as possible with existing log4j.xml files > >meant for use with the, now deprecated, DOMConfigurator, since many > >include the debug attribute set to false. > > I think you are incorrectly assuming that setting the debug flag to false > gets interpreted as true. > > debug="false" is interpreted as debug set to false. > debug="true" is interpreted as debug set to true. > debug="" is interpreted as debug set to true. > debug="hello_i_just_made_a_typo_when_writing_this" would also be > interpreted as debug set to true. > > In short, if the debug flag is present, its value defaults to true, except > if set to false. :-) > > This interpretation of the debug flag has been in log4j for a very long > time. It's not new to Joran. Nobody has ever complained about it although > that does not mean it's not stupid or right. > Ok, I think we are talking past each other. The fact is, I have debug="false" in my log4j.xml and JoranConfigurator spits out internal debugging. When I remove debug="false" from log4j.xml, JoranConfigurator no longer spits out inernal debugging. The behavior you describe above is what I expect. The behavior I actually get, as I've described, doesn't match the expected behavior. As such, there must be a bug of some sort. Jake > > > -- > Ceki G�lc� > > The complete log4j manual: http://qos.ch/eclm > Professional log4j support: http://qos.ch/log4jSupport > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
