Hi again, > I don't think any users actually use POILogger in their code,or? Timewise in parallel I thought the same and applied the patch.
> e.g. by stating that after 2 releases in deprecated state we can remove > things for good. +1 > Regarding slf4j, we could also look at commons-logging at my $dayjob we had a websphere 8 migration some time ago and I'm not sure, if it was because someone put commons-logging in the shared-library which all the portal projects had to use or if it was in the server lib path [1] ... in the end, all the projects had to remove their own commons-logging.jar and stick with the global version. Classloading-order was also an issue. Don't know how configuration was handled. We usually worked with our own log4j.jar and PARENT_LAST, but not all projects were allowed to. So since then JCL sticks with some negative memory, although it's not JCLs fault. Maybe another note to POILogger ... usually the NullLogger will be used, so even if we sparsely log warnings/errors, they will be ignored by default ... that's my main motivation for this, to log more and to know that the user will eventually see it in the log ... and system.properties to activate a feature is not so practically ... A similar topic is the usage of other libs - of course this might be a license issue and if it is really necessary, i.e. if we should use JDK features vs. another/reference impl. I don't think that's a problem nowadays (e.g. sizewise) for standalone/web applications, but don't know about Android apps - maybe someone can shed a light on it? Is there a good page about what to look for when providing a library for Android apps? Andi. [1] http://blog.xebia.com/2009/04/10/logging-in-websphere-application-server-using-apache-commons-logging-and-log4j/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
