On 11/28/2008 3:47 AM, Ceki Gulcu wrote: > > Hello Jacob, > > Comments inline. > > Jacob Kjome wrote: > >> Log4j 1.2.xx contains a RepositorySelector interface with no >> implementation and no >> well defined way of installing one. This was addressed in Log4j 1.3 >> (you must >> recall, no?)... but that died on the vine. Ideally application >> containers would >> support it but, like you say, that cannot be easily addressed. >> Ultimately, >> application containers don't have to provide any special support for >> it as long as >> logging implementations provide basic support for this themselves. So >> this is, >> indeed, "easily addressed" though maybe not "ideally addressed". > > RepositorySelectors was a 1.3 feature? How time flies. >
Seriously? Ok, moving right along then... >> And it's a feature killer. Seems like there ought to be some way to >> address it? >> The repository selector is a great idea that needs to evolve into >> something less >> functionally fragile. > > It should not be difficult to write a SLF4J binding for log4j which > supports repository selectors. > ...which would require Log4j to directly implement the SLF4J interfaces, no? Doubtful for 1.2.xx. >>>> 3. Even implementations that purport to support respository selectors >>>> fail to truly support them in practice as evidenced by the fact that >>>> Logback - >>>> having been in full release for a good while - is just now being >>>> fixed to properly >>>> support them. > >>> The problem was actually in SLF4J. >> >> Hmmm... Except that you said "I am in the process of fixing bugs >> related to >> context selectors in logback." > > Yes, you are right. There were minor issues in logback code as well but > the critical bug was in SLF4J. I started looking into context selectors > while fixing an issue filed against logback. > >>> There are plenty of servers containing multiple applications. In such >>> cases, separation of logging can be accomplished by embedding a copy of >>> log4j.jar in the application itself. > >> >> This works very well in Tomcat standalone, no matter the global server >> classpath, >> because of child-first classloading. Other servers, not so much >> because they tend >> to use parent-first classloading. Some have the option to use >> child-first. >> However, in my experience, Tomcat is the only one that reliably supports >> child-first classloading. So, if Log4j is on the global container >> classpath, kiss >> per/application logging goodbye without the repository selector. >> Frankly, I'm >> surprised you would make this argument since it's one that's always >> been available >> since well before the concept of the repository selector. The fact >> that the >> repository selector concept even exists is evidence that the "simple" >> solution >> didn't fully meet the needs of per/application logging separation. >> Mind you, >> that's not to say that the repository selector concept finally met the >> need. No >> solution I've seen so far has been a panacea. > > Every container has some quirk in the way it handles class loading. The > servers I have had experience with, namely Tomcat, Jetty, Weblogic 9, > JBoss and Geronimo all perform child first (or local first) class > loading. However, the exact details of the class loader architecture of > each server is very difficult to assess because each has its own quirks > which sometimes change from version to version (of the same server). > This partially explains the success of SLF4J which uses the dumbest > binding strategy possible. > > Returning to your comment, log4j does not need to be on global class > container. > If the container uses log4j (as in jboss), they can hide or > not export log4j classes to the applications it hosts. So, you're saying that certain new containers have sophisticated classloaders (OSGi I'm guessing?) that separate the server libraries from the application libraries. That's very handy and something I haven't experienced for myself yet. My company uses Weblogic 8.1 update 6 and 9.1, neither of which has such sophisticated classloading behavior (that I'm aware of). All of what you've been saying so far seems to rely either on bleeding edge functionality or not-yet-existent functionality. > > There is also a question of shared libraries. This is a really tough one > to crack as mere logger contexts are insufficient. > How so? Of course the libraries must use non-static loggers, but what else prevents shared libraries from participating in a logger context where the logging implementation exists in the same (or parent) classloader? You still haven't detailed your alternative solution the logger separation problem. If you have one, please detail. Saying over and over that there other other ways to separate application logging without the repository selector concept, but never describing what they are, is not particularily convincing. If there really are alternate, and better, ways of separating logging I'm prepared to drop repository selectors in a heartbeat. But forgive me if I remain skeptical. Jake --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
