[
https://issues.apache.org/jira/browse/PIVOT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508695#comment-13508695
]
Steven Swor commented on PIVOT-882:
-----------------------------------
I see two major contenders for this: java.util.logging and SLF4J.
I'm inherently biased towards SLF4J because, for enterprise applications, I
like the idea of developing against an API and relying on the application to
provide the implementation. Should an implementation not be available on the
classpath, SLF4J will fallback to a no-op implementation, meaning it won't
break an application just because a developer forgot to add the implementation
to a Pivot project. In Maven projects, it's trivial to add SLF4J and its
implementations as dependencies (one of: logback-classic, slf4j-jdk14,
slf4j-log4j12, et cetera). However, not all Pivot projects are Maven projects,
and (even if they were), using SLF4J would add additional steps to getting a
fresh Pivot project up and running with logging enabled, which would require
additional documentation. Also, I've never used SLF4J in applet code, so I
don't know what (if any) gotchas there are.
JUL has the advantage of already shipping with Java versions 1.4 and above, so
it doesn't add any additional dependency overhead. The APIs are designed with
applet security in mind (see java.util.logging.Logger.getAnonymousLogger()).
However, JUL is both an API and an implementation. The combination of SLF4J
and Logback seems to be a pretty popular logging setup for enterprise
applications (Log4J is also still pretty common, although it appears to no
longer be under active development), so choosing JUL for Pivot would mean that
enterprise applications which already use SLF4J/Logback/Log4J would either have
to maintain separate logging configuration files (one for Logback/Log4J and one
for JUL) or incur additional dependencies to bridge all the logging systems
together (there's a pretty in-depth analysis of this at
http://www.slf4j.org/legacy.html, which mentions significant performance hits
when using jul-to-slf4j).
> Internal Logging Mechanism
> --------------------------
>
> Key: PIVOT-882
> URL: https://issues.apache.org/jira/browse/PIVOT-882
> Project: Pivot
> Issue Type: Improvement
> Affects Versions: 2.0, 2.0.1, 2.0.2
> Reporter: Steven Swor
> Priority: Minor
> Labels: logging
> Fix For: 2.1
>
>
> As of 2.0.2, Pivot does some internal logging using calls to System.out and
> System.err (for example, when using org.apache.pivot.json.JSONSerializer with
> verbose = true).
> It would be really nice if Pivot could leverage a more robust logging API
> instead, but certain design decisions come into play when choosing a logging
> framework.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
