From: Christiaan F. <chr...@ad...> - 2007-02-19 16:24:59
|
Hello all, I would like to propose a change in how we do logging in Aperture. Currently we handle logging by declaring a static Logger instance in every class where logging is required. This is what we (Aduna) were doing ourselves at the time when we proposed this. In the mean time we are doing things differently in Sesame and other Aduna projects: - We are using SLF4J (www.slf4j.org), a logging facade that has connectors for all major logging frameworks - loggers are instance variables rather than class variables. I would like to propose the same for Aperture. The last change is in my opinion the most important one. We have experienced the hard way that static loggers can be harmful in applications that are more complex than a simple application running in a single JVM. For example, when you are running multiple webapps in a single servlet container and these webapps share code containing static Loggers, it depends on the class loader strategy/settings of that container whether each app has its own Loggers or whether they are shared between these webapps. In one scenario, we were deploying two different webapps wit shared code in Tomcat. All log messages of the shared code were appended to the log file of one of them. Things like log levels are determined by whichever app changes the settings last. My guess is that every environment with custom ClassLoaders may show similar problems. For example, I wonder what happens in an OSGi-based application. The second change (switch to SLF4J) is of lesser importance but may still be nice. On the Sesame developers mailing list we had a long discussion on what logging approach to use. Basically SLF4J was chosen because it's a logging router (i.e. is able to work with any major logging implementation; java.util.logging, log4j, commons-logging, ...) and connecting it to whatever logging implementation you are using in your app is trivial: just put the SLF4J implementation for that framework in your classpath. Granted, the same binding can probably also be made between java.util.logging and another implementation, but this is exactly what SLF4J is already solving for you. Also, SLF4J was made with these class-loading issues in mind. Note that when you are using Sesame 2, you already need to setup your system for SLF4J (i.e. put the API jar file and an impl jar file in your classpath), so when Aperture would also use SLF4J, this effectively means no extra work. I would be happy to code this switch myself. Any ideas, objections? Chris -- |
From: Christiaan F. <chr...@ad...> - 2007-02-19 17:34:06
|
Leo Sauermann wrote: > Hi all, Hi, thanks for the quick reply. BTW: you didn't cc aperture-devel so only I got your reply. > I would strongly object using any more complicated logger frameworks. > For a crawling framework like aperture, java.util.Logging is fair enough. I guess I saw this one coming ;) To be totally honest, I don't have a strong preference for either one. My only priority is to get things working correctly (hence the change to instance loggers), and while I'm at it I could easily make any other changes to logging that we might wish for. > As said in other mails to the sesame2 mailinglist, all logging > frameworks have a limited life span, > given the fact that SUN has now standardized logging. This is where my lack of knowledge is showing. I have never used anything else but java.util.logging. I have no idea whether the other frameworks still have any raison d'être other than "for historic reasons". > so an abstraction framework abstracting away different logging > frameworks will not be needed in a few years. > I see no reason for using SLF4J. IF you are dependent on some older > logging, just do this: > > You can forward logging from java.util.Logging to any other framework, > if you want. Its something like > // remove java loggers from aperture > Logger.getLogger(org.semanticdesktop.aperture).removeAllHandlers() // > this method may not exist, but its possible to code in two lines > // forward the java log messages to another framework > Logger.getLogger(org.semanticdesktop.aperture).addHandler(yourHandlerforwardingJavaLoggerToTheLegacyLoggingFrameworkOfYourChoice) > > > About static/instance logging, if this is needed, just use this code, > I had some classes (which have subclasses) where this helped: > > protected Logger log = Logger.getLogger(this.getClass().getName); Yeah, that's what I also had in mind, expect for that I would keep the instance private: subclasses should create their own logger, so that you can see which *class* is doing the logging. Else subclasses that override methods and use the logger of the overridden class get very curious log messages. Only in very specific cases, where a lot of loggers are generated and the cost becomes non-negligible (never seen yet), could we look at such approaches. I will at least make the switch to instance loggers then. Chris -- |
From: Christiaan F. <chr...@ad...> - 2007-02-20 12:48:00
|
Christiaan Fluit wrote: > To be totally honest, I don't have a strong preference for either one. > My only priority is to get things working correctly (hence the change to > instance loggers), and while I'm at it I could easily make any other > changes to logging that we might wish for. [...] > I will at least make the switch to instance loggers then. I was already halfway the conversion to instance loggers (using java.util.logging), when a chat with Herko gave me some more insight into the actual issues at hand. Apparently there is a fundamental problem with the JDK's own logging. The loggers obtained by Logger.getLogger(..) are all registered in a LogManager. According to LogManager's Javadoc: "There is a single global LogManager object that is used to maintain a set of shared state about Loggers and log services." This gets problematic in servlet containers. Usually, each webapp has its own ClassLoader so that there will be no conflicts between the same classes or versions of classes between different webapps. However, this ClassLoader will first invoke its parent (a container-wide ClassLoader) before any attempt to load the Class itself. See e.g. http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html. As Java logging is part of the JRE, it will be loaded by this system-wide ClassLoader and therefore there will be only one LogManager for the entire container. It doesn't matter whether you use static or instance loggers, as eventually all org.semanticdesktop.aperture.* loggers will be put in the same hierarchy. For this reason, Sesame is not only using SLF4J as a logging facade, but also log4j as the concrete implementation, completely abandoning java.util.logging. This will prevent problems we had with log files of multiple webapps getting messed up. Looking further at LogManager's Javadoc, I see that it is possible to specify the LogManager implementation class, but I doubt that that is the route we want to go. At the moment I see no other workaround. Given this insights, are you still opposed to use SLF4J? At least application developers then have a choice. It solves all problems in a very straightforward way. In AutoFocus, I am still happily using the SLF4J implementation based on java.util.logging but in the new Metadata Server we will surely want to use something else. Regards, Chris -- |
From: Christiaan F. <chr...@ad...> - 2007-02-20 13:03:56
|
Christiaan Fluit wrote: > Looking further at LogManager's Javadoc, I see that it is possible to > specify the LogManager implementation class, but I doubt that that is > the route we want to go. At the moment I see no other workaround. Right after I send this mail, I discovered that Tomcat 5.5+ does in fact have a workaround: "The default implemenatation of java.util.logging provided in the JDK is too limited to be useful. A limitation of JDK Logging appears to be the inability to have per-web application logging, as the configuration is per-VM. As a result, Tomcat will, in the default configuration, replace the default LogManager implementation with a container friendly implementation called JULI, which addresses these shortcomings." See http://tomcat.apache.org/tomcat-5.5-doc/logging.html. This gives us some relief but the problem remains that it depends on the servlet container whether logging will behave as expected or not. Chris -- |
From: Herko t. H. <her...@ad...> - 2007-02-20 13:46:43
|
> This gives us some relief but the problem remains that it depends on the > servlet container whether logging will behave as expected or not. Not just servlet containers, any managed container that needs to keep code from one classloader isolated from other code (e.g. OSGi containers) will run into the same issue. This LogManager issue is one of the issues that I believe will keep other logging frameworks alive, even with a standard logging framework available in Java SE. In addition, the huge current installed base of other logging frameworks (most notably log4j) makes it important to consider the use of Aperture within applications that use different logging frameworks. IMO, a thin, easy-to-use abstraction that specifically avoids classloading issues gives Aperture users the necessary freedom to choose their own logging implementation based on their specific needs. Herko ter Horst Senior Software Engineer -- Aduna - Guided Exploration www.aduna-software.com Prinses Julianaplein 14-b 3817 CS Amersfoort The Netherlands +31-33-4659987 (office) |
From: Leo S. <leo...@df...> - 2007-02-22 16:39:20
|
Es begab sich aber da Herko ter Horst zur rechten Zeit 20.02.2007 14:46 folgendes schrieb: >> This gives us some relief but the problem remains that it depends on the >> servlet container whether logging will behave as expected or not. >> > > Not just servlet containers, any managed container that needs to keep > code from one classloader isolated from other code (e.g. OSGi > containers) will run into the same issue. > > This LogManager issue is one of the issues that I believe will keep > other logging frameworks alive, even with a standard logging framework > available in Java SE. > > In addition, the huge current installed base of other logging frameworks > (most notably log4j) makes it important to consider the use of Aperture > within applications that use different logging frameworks. IMO, a thin, > easy-to-use abstraction that specifically avoids classloading issues > gives Aperture users the necessary freedom to choose their own logging > implementation based on their specific needs. > It is thin, but its not as easy to use as java logging. You have to read additional documentation, developers need more training, and you have two problems and two points of failure when using it, first SLF4J can fail and then the underlying framework can fail. Then, you have to manage two additional configuration file formats - SLF4J and the underlying logger framework. If people use alternate logging implementations as default logging for their applications, then they can use some forwarding mechanism to catch the java logger messages and forward them to the log-framework of their choice. This guy suggests to only use non-standard loggers if you need their features. I don't see that we need these features. http://java.sys-con.com/read/48541_2.htm I see that using a non-standard logger + abstraction layer always cries for having two additional jars in your code, two jars that are unneeded. Again, all non-standard logger frameworks are pre-2002, we have 2007 now. Also, logging isn't that mysterious rocket science, and java.logging is ok enough for most applications, why think about this stuff and waste endless time to choose the "right" logging framework if SUN provides one that works for 90% of all cases pretty well? If its just the nerdy discussion "which logging framework has better features, mine is better than yours", I would definitly go for jul. JUL was created as a copy/paste of all the other framworks that were out there before 2002, it is a JSR, its the right descision. Still, if aduna insists on using SLF4J because of customer demands, I agree to switch to it. best Leo > Herko ter Horst > Senior Software Engineer > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2007-02-22 21:29:09
|
> It is thin, but its not as easy to use as java logging. > You have to read additional documentation, developers need more > training, and you have two problems and two points of failure when using > it, first SLF4J can fail and then the underlying framework can fail. From a coding point of view, I think SLF4J is actually easier to use than Java logging. Of course, if all you have ever used before is Java logging, then yes, this is an additional thing to learn, but it's really simple (it's called Simple Logging Framework 4 Java for a reason), not in the least because the concepts are pretty much the same across all frameworks. As far as reliability goes: because SLF4J doesn't actually do the decision-making, formatting or actual logging, the chances of anything going seriously wrong within the SLF4J framework are very small. All it does is accept logging calls and forward them to the actual logging implementation. > Then, you have to manage two additional configuration file formats - > SLF4J and the underlying logger framework. Not true, because SLF4J is *only the interface* to program to. The actual framework implementation controls what type of configuration is needed, so you can keep using your existing Java Logging or log4j configuration without change. > If people use alternate logging implementations as default logging for > their applications, then they can use some forwarding mechanism to catch > the java logger messages and forward them to the log-framework of their > choice. All these forwarding mechanisms are exactly what SLF4J already provides. JUL, log4j, Apache Commons Logging are all supported out of the box. > This guy suggests to only use non-standard loggers if you need their > features. I don't see that we need these features. > http://java.sys-con.com/read/48541_2.htm SLF4J isn't an alternative for Java Logging or Log4J in the way described in that article. As such it doesn't have "more" or "better" features. For example, SLF4J doesn't have handlers, formatters or whatever. All it does is provide the *library* programmer with an interface to program too. The actually logging is done by whatever logging implementation is selected for the end-user *application*. > I see that using a non-standard logger + abstraction layer always cries > for having two additional jars in your code, two jars that are unneeded. > Again, all non-standard logger frameworks are pre-2002, we have 2007 now. SLF4J was started in 2005 because it was obvious at that time that multiple logging implementations were available which would continue to be used for a long time to come. For example, log4j isn't going away anytime soon. It has a huge installed base and I imagine that most of those applications will continue to use log4j for new versions. > Also, logging isn't that mysterious rocket science, and java.logging is > ok enough for most applications, why think about this stuff and waste > endless time to choose the "right" logging framework if SUN provides one > that works for 90% of all cases pretty well? The problem is that we don't control "most applications". Most applications are written by others and they will select the logging implementation of their preference. Being able to use the Aperture libraries in any application, regardless of the logging implementation it uses seems like a big plus to me. So if you want to keep using JUL in your applications based on Aperture, that's fine, no problem at all. If at Aduna we want to start using log4j for our web-based products because we don't want to rely on the servlet container to solve the LogManager problem for us, that's fine too. If <insert random Apache project here> wants to keep using Apache Commons Logging for their application, but still be able to integrate Aperture, that will work as well. > If its just the nerdy discussion "which logging framework has better > features, mine is better than yours", I would definitly go for jul. JUL > was created as a copy/paste of all the other framworks that were out > there before 2002, it is a JSR, its the right descision. It's not a discussion of better or more features, it's a discussion of forcing a logging *implementation* on users of the library because we selected a particular logging *API*. SLF4J allows you to select the logging implementation at *deployment* time just by dropping in the correct jar file. Cheers, Herko |
From: Leo S. <leo...@df...> - 2007-02-27 14:23:27
|
Hi all, Es begab sich aber da Herko ter Horst zur rechten Zeit 22.02.2007 22:28 folgendes schrieb: >> It is thin, but its not as easy to use as java logging. >> You have to read additional documentation, developers need more >> training, and you have two problems and two points of failure when using >> it, first SLF4J can fail and then the underlying framework can fail. >> > > From a coding point of view, I think SLF4J is actually easier to use > than Java logging. they all drill down to something like this, I don't see much ways to make it any easier: Log log = ....getLogger(...); log.debug("blub"); > Of course, if all you have ever used before is Java > logging, then yes, this is an additional thing to learn, but it's really > simple (it's called Simple Logging Framework 4 Java for a reason), not > in the least because the concepts are pretty much the same across all > frameworks. > > As far as reliability goes: because SLF4J doesn't actually do the > decision-making, formatting or actual logging, the chances of anything > going seriously wrong within the SLF4J framework are very small. All it > does is accept logging calls and forward them to the actual logging > implementation. > sure, SLF4J can break and the underlying framework > >> Then, you have to manage two additional configuration file formats - >> SLF4J and the underlying logger framework. >> > > Not true, because SLF4J is *only the interface* to program to. The > actual framework implementation controls what type of configuration is > needed, so you can keep using your existing Java Logging or log4j > configuration without change. > > I meant, you can now screw up the SLF4J configuraiton file (= configuring which real framework to use) and the configuration file of the actual logging framework. = 2 file formats, 2 points of failure. >> If people use alternate logging implementations as default logging for >> their applications, then they can use some forwarding mechanism to catch >> the java logger messages and forward them to the log-framework of their >> choice. >> > > All these forwarding mechanisms are exactly what SLF4J already provides. > JUL, log4j, Apache Commons Logging are all supported out of the box. > If you have the problem of not using Java Logging, you can forward JAva logging to XYZ. If SLF4J makes this easier, its good for those people who don't use Java logging, they can then forward messages generated by Java Logging to XYZ., for java-logging based architectures, nothing is needed. > >> This guy suggests to only use non-standard loggers if you need their >> features. I don't see that we need these features. >> http://java.sys-con.com/read/48541_2.htm >> > > SLF4J isn't an alternative for Java Logging or Log4J in the way > described in that article. As such it doesn't have "more" or "better" > features. For example, SLF4J doesn't have handlers, formatters or > whatever. All it does is provide the *library* programmer with an > interface to program too. The actually logging is done by whatever > logging implementation is selected for the end-user *application*. > > That is surely true, but all these question only come up for people who have needs *beyond* java logging. The point is not what SLF4J does or does not, its that * in 90% of all cases, Java logging is enough * if not, you can forward messages generated by Java logging to XYZ to have more features. in 10% of the cases, you can then use SLF4J/Log4j etc..... >> I see that using a non-standard logger + abstraction layer always cries >> for having two additional jars in your code, two jars that are unneeded. >> Again, all non-standard logger frameworks are pre-2002, we have 2007 now. >> > > SLF4J was started in 2005 because it was obvious at that time that > multiple logging implementations were available which would continue to > be used for a long time to come. For example, log4j isn't going away > anytime soon. It has a huge installed base and I imagine that most of > those applications will continue to use log4j for new versions. > Still, if we start a NEW framework, from scratch, like Aperture, we don't have to care for all these legacy things. If you want to use aperture in a legacy logging environment, forward JUL to the framework you use. > >> Also, logging isn't that mysterious rocket science, and java.logging is >> ok enough for most applications, why think about this stuff and waste >> endless time to choose the "right" logging framework if SUN provides one >> that works for 90% of all cases pretty well? >> > > The problem is that we don't control "most applications". Most > applications are written by others and they will select the logging > implementation of their preference. Being able to use the Aperture > libraries in any application, regardless of the logging implementation > it uses seems like a big plus to me. > > So if you want to keep using JUL in your applications based on Aperture, > that's fine, no problem at all. If at Aduna we want to start using log4j > for our web-based products because we don't want to rely on the servlet > container to solve the LogManager problem for us, that's fine too. If > <insert random Apache project here> wants to keep using Apache Commons > Logging for their application, but still be able to integrate Aperture, > that will work as well. > Yes, that would make it easier for these to use the logging framework of choice. > >> If its just the nerdy discussion "which logging framework has better >> features, mine is better than yours", I would definitly go for jul. JUL >> was created as a copy/paste of all the other framworks that were out >> there before 2002, it is a JSR, its the right descision. >> > > It's not a discussion of better or more features, it's a discussion of > forcing a logging *implementation* on users of the library because we > selected a particular logging *API*. SLF4J allows you to select the > logging implementation at *deployment* time just by dropping in the > correct jar file. > ok, I was not on this situation before, so I trust you guys learned from your Sesame experience that you are sure that this is a problem enough and that you had this problem appear in the past and lost money because of it, otherwise it wouldn't be so important for you, or? if it can't be done with JUL, we have to go with SLF4J.... so be it :-) best Leo > Cheers, > > Herko > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Leo S. <leo...@df...> - 2007-03-01 17:28:56
|
Hi Chris, Herko, sorry for being late, we had this important meeting :-| For short: * ok, convinced. I see the point with log manager and the argumentation is clear * my hope was that by sticking to JUL I don't have to think about logging anymore, but since JUL has these bugs and there are still so many other frameworks out there, using SLF4J does not hurt and helps in many cases when other loggers are to be used. Still, I hope that in some years, they will all be history and only JUL remains.... (personal hope, not related to aperture) * I am ok with SLF4J one final question, about logging as such: Doesn't org.apache.commons.log do the same as SLF4J, namely log forwarding to log implementations, and isn't commons.log more popular than SLF4J? I don't know .... if SLF4J and commons.log are isomorphic, we may want to chose the more popular one Nevertheless, I am ok with SLF4J and apache.commons.log, and I think you guys have better experience with SLF4J, so as you are already on the SLF4J bandwagon, and have experience with it, its cheaper to use SLF4J than apache commons. the reason why I wanted to discuss is my faint hope to make things simpler, which wasn't possible :-| thanks for being so patient, best Leo Es begab sich aber da Christiaan Fluit zur rechten Zeit 27.02.2007 16:48 folgendes schrieb: > Leo Sauermann wrote: > >> I meant, you can now screw up the SLF4J configuraiton file (= >> configuring which real framework to use) >> and the configuration file of the actual logging framework. >> = 2 file formats, 2 points of failure. >> > [snip] > >> If you have the problem of not using Java Logging, >> you can forward JAva logging to XYZ. >> If SLF4J makes this easier, its good for those people who don't use Java >> logging, >> they can then forward messages generated by Java Logging to XYZ., >> for java-logging based architectures, nothing is needed. >> > [snip] > >> The point is not what SLF4J does or does not, its that >> * in 90% of all cases, Java logging is enough >> * if not, you can forward messages generated by Java logging to XYZ to >> have more features. >> >> in 10% of the cases, you can then use SLF4J/Log4j etc..... >> > [snip] > >> If you want to use aperture in a legacy logging environment, forward JUL >> to the framework you use. >> > [snip] > >> ok, I was not on this situation before, >> so I trust you guys learned from your Sesame experience that you are >> sure that this is a problem enough >> and that you had this problem appear in the past and lost money because >> of it, >> otherwise it wouldn't be so important for you, or? >> >> if it can't be done with JUL, we have to go with SLF4J.... so be it :-) >> > > Hi Leo, > > Although I appreciate your willingness to go along with a switch to > SLF4J, I'd rather have you agree with us on the necessity of it :) > > I think you are missing an important point in your line of reasoning, > namely the effect it has on end users: not the coders integrating > Aperture but the people running apps like AutoFocus, Metadata Server and > Gnowsis. > > The whole problem boils down to the simple fact that there is a single > shared LogManager in JUL that *cannot* be overridden from within your > application code. It cannot be solved just by forwarding the log > messages to another logging implementation; whether or not you will face > this problem depends on the particular classloading strategy of your > application server or whatever your app runs on. For AutoFocus and > probably Gnowsis there is no problem (single app running in a single > JVM) but for webapps it's a totally different story. As soon as you log > to a java.util.logging.Logger you're screwed. > > This has already lead to serious problems at one of our customers, which > took us some time to figure out. This client deployed both Aduna > Metadata Server and Aduna Spectacle (a very common scenario for us - I'd > say 90% of our projects, not 10%) in the same servlet container and > consequently got messed up log files because both apps share code. Not > that we went bankrupt on this issue, but strictly speaking: yes, we lost > money on this! > > There are workarounds such as the one provided by Tomcat 5.5+ but these > are always "external", i.e. not something that you can include in the > webapp itself. This means that the end user documentation of these > webapps needs to mention the issue and put the responsibility on the end > user to either choose an application server that has a fix for the > LogManager problem or not run several of our apps on the same app > server. And trust me, there will be clients who don't understand or > ignore the warning and run into the same issue again, leading to much > frustration, distrust, etc. Also, in big corporations we often don't > have the ability to enforce the use of say a particular Tomcat version, > it's "make it work in our current infrastructure or > thanks-but-no-thanks" (= much more money lost). > > Rather than document the issue and hope for the best, I would like to > strive for a solution that solves the problem once and for all, so that > installation of our webapps becomes fool-proof again. In Sesame this has > been achieved by using the SLF4J API and the SLF4J implementation for > log4j. JUL is not used in this chain and it all becomes a non-issue. No > need to explain our end users anything at all. > > Granted, SLF4J has some consequences: > > - More jar files to bundle (note: SLF4J needs no configuration file, > property settings or whatever, configuring it only means putting the > SLF4J implementation for your logging implementation of choice in your > classpath, similar to RDF2Go) > > - It puts an extra burden on another class of Aperture users, namely the > coders that integrate Aperture into their own apps. However, this is > exactly where the burden should be: I have no problems informing > developers of the issues they might run into when using Aperture. > > > Best regards, > > Chris > -- > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Arjohn K. <arj...@ad...> - 2007-03-06 20:04:37
Attachments:
arjohn.kampman.vcf
|
Leo Sauermann wrote: > Hi Chris, Herko, > > sorry for being late, we had this important meeting :-| > > For short: > * ok, convinced. I see the point with log manager and the argumentation > is clear > * my hope was that by sticking to JUL I don't have to think about > logging anymore, but since JUL has these bugs and there are still so > many other frameworks out there, using SLF4J does not hurt and helps in > many cases when other loggers are to be used. Still, I hope that in some > years, they will all be history and only JUL remains.... (personal hope, > not related to aperture) > * I am ok with SLF4J > > one final question, about logging as such: > Doesn't org.apache.commons.log do the same as SLF4J, namely log > forwarding to log implementations, and isn't commons.log more popular > than SLF4J? > I don't know .... if SLF4J and commons.log are isomorphic, we may want > to chose the more popular one > > Nevertheless, I am ok with SLF4J and apache.commons.log, and I think you > guys have better experience with SLF4J, > so as you are already on the SLF4J bandwagon, and have experience with > it, its cheaper to use SLF4J than apache commons. SLF4J and apache commons logging (ACL) indeed are quite similar. Also, ACL is around much longer and is (still) more popular. However, SLF4J was developed because of some fundamental classloading problems in ACL. SLF4J has none of these problems. For an in-depth discussion, see the following document: http://www.qos.ch/logging/classloader.jsp (Note: this article has been written by the author of SLF4J). -- Arjohn |
From: Christiaan F. <chr...@ad...> - 2007-02-27 15:48:29
|
Leo Sauermann wrote: > I meant, you can now screw up the SLF4J configuraiton file (= > configuring which real framework to use) > and the configuration file of the actual logging framework. > = 2 file formats, 2 points of failure. [snip] > If you have the problem of not using Java Logging, > you can forward JAva logging to XYZ. > If SLF4J makes this easier, its good for those people who don't use Java > logging, > they can then forward messages generated by Java Logging to XYZ., > for java-logging based architectures, nothing is needed. [snip] > The point is not what SLF4J does or does not, its that > * in 90% of all cases, Java logging is enough > * if not, you can forward messages generated by Java logging to XYZ to > have more features. > > in 10% of the cases, you can then use SLF4J/Log4j etc..... [snip] > If you want to use aperture in a legacy logging environment, forward JUL > to the framework you use. [snip] > ok, I was not on this situation before, > so I trust you guys learned from your Sesame experience that you are > sure that this is a problem enough > and that you had this problem appear in the past and lost money because > of it, > otherwise it wouldn't be so important for you, or? > > if it can't be done with JUL, we have to go with SLF4J.... so be it :-) Hi Leo, Although I appreciate your willingness to go along with a switch to SLF4J, I'd rather have you agree with us on the necessity of it :) I think you are missing an important point in your line of reasoning, namely the effect it has on end users: not the coders integrating Aperture but the people running apps like AutoFocus, Metadata Server and Gnowsis. The whole problem boils down to the simple fact that there is a single shared LogManager in JUL that *cannot* be overridden from within your application code. It cannot be solved just by forwarding the log messages to another logging implementation; whether or not you will face this problem depends on the particular classloading strategy of your application server or whatever your app runs on. For AutoFocus and probably Gnowsis there is no problem (single app running in a single JVM) but for webapps it's a totally different story. As soon as you log to a java.util.logging.Logger you're screwed. This has already lead to serious problems at one of our customers, which took us some time to figure out. This client deployed both Aduna Metadata Server and Aduna Spectacle (a very common scenario for us - I'd say 90% of our projects, not 10%) in the same servlet container and consequently got messed up log files because both apps share code. Not that we went bankrupt on this issue, but strictly speaking: yes, we lost money on this! There are workarounds such as the one provided by Tomcat 5.5+ but these are always "external", i.e. not something that you can include in the webapp itself. This means that the end user documentation of these webapps needs to mention the issue and put the responsibility on the end user to either choose an application server that has a fix for the LogManager problem or not run several of our apps on the same app server. And trust me, there will be clients who don't understand or ignore the warning and run into the same issue again, leading to much frustration, distrust, etc. Also, in big corporations we often don't have the ability to enforce the use of say a particular Tomcat version, it's "make it work in our current infrastructure or thanks-but-no-thanks" (= much more money lost). Rather than document the issue and hope for the best, I would like to strive for a solution that solves the problem once and for all, so that installation of our webapps becomes fool-proof again. In Sesame this has been achieved by using the SLF4J API and the SLF4J implementation for log4j. JUL is not used in this chain and it all becomes a non-issue. No need to explain our end users anything at all. Granted, SLF4J has some consequences: - More jar files to bundle (note: SLF4J needs no configuration file, property settings or whatever, configuring it only means putting the SLF4J implementation for your logging implementation of choice in your classpath, similar to RDF2Go) - It puts an extra burden on another class of Aperture users, namely the coders that integrate Aperture into their own apps. However, this is exactly where the burden should be: I have no problems informing developers of the issues they might run into when using Aperture. Best regards, Chris -- |
From: Leo S. <leo...@df...> - 2007-02-22 16:20:51
|
Hi Chris, Es begab sich aber da Christiaan Fluit zur rechten Zeit 20.02.2007 14:03 folgendes schrieb: > Christiaan Fluit wrote: > >> Looking further at LogManager's Javadoc, I see that it is possible to >> specify the LogManager implementation class, but I doubt that that is >> the route we want to go. At the moment I see no other workaround. >> > > Right after I send this mail, I discovered that Tomcat 5.5+ does in fact > have a workaround: > Yeah, that is what I would also have thought. If java logging is the default and logger of choice, I would have expected that it would not cause problems in web applications. Web applications are soo common that its somehow natural that logging should work. So, I would still vote for java util logging, and if this makes bugs, fix them or find a fix. best Leo > "The default implemenatation of java.util.logging provided in the JDK is > too limited to be useful. A limitation of JDK Logging appears to be the > inability to have per-web application logging, as the configuration is > per-VM. As a result, Tomcat will, in the default configuration, replace > the default LogManager implementation with a container friendly > implementation called JULI, which addresses these shortcomings." > > See http://tomcat.apache.org/tomcat-5.5-doc/logging.html. > > This gives us some relief but the problem remains that it depends on the > servlet container whether logging will behave as expected or not. > > > Chris > -- > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Leo S. <leo...@df...> - 2007-02-22 15:31:44
|
Es begab sich aber da Christiaan Fluit zur rechten Zeit 19.02.2007 18:33 folgendes schrieb: > Leo Sauermann wrote: > >> I would strongly object using any more complicated logger frameworks. >> For a crawling framework like aperture, java.util.Logging is fair enough. >> > > I guess I saw this one coming ;) > yes, that was to be expected :-) > To be totally honest, I don't have a strong preference for either one. > My only priority is to get things working correctly (hence the change to > instance loggers), and while I'm at it I could easily make any other > changes to logging that we might wish for. > > >> As said in other mails to the sesame2 mailinglist, all logging >> frameworks have a limited life span, >> given the fact that SUN has now standardized logging. >> > > This is where my lack of knowledge is showing. I have never used > anything else but java.util.logging. I have no idea whether the other > frameworks still have any raison d'être other than "for historic reasons". > Me neither, but I know that Java logging did not exist before java 1.4 and that the logging frameworks were started before this. > >> so an abstraction framework abstracting away different logging >> frameworks will not be needed in a few years. >> I see no reason for using SLF4J. IF you are dependent on some older >> logging, just do this: >> >> You can forward logging from java.util.Logging to any other framework, >> if you want. Its something like >> // remove java loggers from aperture >> Logger.getLogger(org.semanticdesktop.aperture).removeAllHandlers() // >> this method may not exist, but its possible to code in two lines >> // forward the java log messages to another framework >> Logger.getLogger(org.semanticdesktop.aperture).addHandler(yourHandlerforwardingJavaLoggerToTheLegacyLoggingFrameworkOfYourChoice) >> >> >> About static/instance logging, if this is needed, just use this code, >> I had some classes (which have subclasses) where this helped: >> >> protected Logger log = Logger.getLogger(this.getClass().getName); >> > > Yeah, that's what I also had in mind, expect for that I would keep the > instance private: subclasses should create their own logger, so that you > can see which *class* is doing the logging. Else subclasses that > override methods and use the logger of the overridden class get very > curious log messages. Only in very specific cases, where a lot of > loggers are generated and the cost becomes non-negligible (never seen > yet), could we look at such approaches. > On the other hand, using private loggers may have the effect that you don't get the real classname doing the logging - this is also bad when having generic superclasses that do important things. Lets assume something like AbstractCrawler{ private Logger log ... startCrawling() { log.fine("I start crawling now"); } FileCrawler extends AbstractCrawler{ private Logger log ... doThings() { log.fine("I am doing things"); } This will result in messages like this (version A): [AbstractCrawler] I start crawling now [FileCrawler] I am doing things When really what you would need is (version B) [FileCrawler] I start crawling now [FileCrawler] I am doing things its easiser to debug (and thats what log messages are for, or?) if you can see all the messages that belong together in one logger. For example, we have a window that shows log messages, sorted by logger. If you use such a display, version A will cause troubles because you don't see the start-message and think: why is the crawler doing things before he even started? In version B, its better. The BEST way to do it, in my opinion is, AbstractCrawler{ protected Logger log = Logger.getLogger(this.getClass().getName); } Subclasses can then access the logger, and all is fine. Messages generated in the superclass use the correct class of the instance. Think of abstract classes, their loggers are pretty useless if you don't know the real instantiated class. Do you know cases where this is not intended and the loggers need to be private? Note, that also creating a logger for each instance creates a LOT of unneeded instances, fills memory and wastes resources, so I would really not do it. Logging is for debugging, and using instance loggers just doesn't pay off for debugging, given the cost we pay during runtime. or? Although i didn't think about it that much.... best Leo > I will at least make the switch to instance loggers then. > > > Chris > -- > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |