You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Curt Arnold (JIRA)" <ji...@apache.org> on 2008/12/04 06:26:44 UTC
[jira] Created: (LOG4J2-27) log4j 2 should implement the SLF4J API
directly
log4j 2 should implement the SLF4J API directly
-----------------------------------------------
Key: LOG4J2-27
URL: https://issues.apache.org/jira/browse/LOG4J2-27
Project: Log4j 2
Issue Type: Wish
Components: API
Reporter: Curt Arnold
A PDF version of jspwiki-log.odf will be attached to this bug.
On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote on log4j-dev:
Hello,
As you are probably aware, more and more projects are adopting the
SLF4J API. I would venture say that SLF4J's adoption rate is roughly
equivalent to that of log4j itself. Although the SLF4J API is not
perfect, most SLF4J users seem to be extremely happy with it.
Harry Metske synthesized various logging paths in JSPWiki
https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp
I was taken aback by the picture he paints. I think we as log4j
committers owe it to Java developers to propose a saner logging model.
Given the multiplicity of logging APIs in the Java world, I propose
that log4j implement the SLF4J API directly. This can be done in the
next version of log4j, say 1.3 or 2.0.
Unfortunately, the adoption of the SLF4J API by log4j will be break
100% compatibility with existing log4j clients. More precisely,
logging statements passing java.lang.Object as the message parameter
will need to be changed to java.lang.String. Assuming that the
proportion of logging statements using objects instead string is
extremely small, comparatively few users will be affected. More
importantly, in my experience, even very large projects can be
migrated to the SLF4J API within half an hour.
There is even a tool called slf4j-migrator to help with such
migration [1].
Is there support for my proposal?
[1] http://www.slf4j.org/migrator.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-27) log4j 2 should implement the SLF4J
API directly
Posted by "Ceki Gulcu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653751#action_12653751 ]
Ceki Gulcu commented on LOG4J2-27:
----------------------------------
There is actually a way to maintain 100% source code compatibility. The org.apache.log4j.Logger/Category classes would cetain their existing method signatures but would delegate to org.apache.log4j.impl.Logger class which would implement the org.slf4j.Logger interface. This is feasible as demonstrated by the log4j-over-slf4j module in SLF4J.
Clients wishing to use the existing log4j classes could continue to do so. Those wishing to standardize on the SLF4J API could do so as well. Direct use of org.apache.log4j.impl.Logger would technically be possible but discouraged.
As described above, there is a way to converge on the SLF4J API without breaking compatibility.
> log4j 2 should implement the SLF4J API directly
> -----------------------------------------------
>
> Key: LOG4J2-27
> URL: https://issues.apache.org/jira/browse/LOG4J2-27
> Project: Log4j 2
> Issue Type: Wish
> Components: API
> Reporter: Curt Arnold
> Attachments: jspwiki-log.pdf
>
>
> A PDF version of jspwiki-log.odf will be attached to this bug.
> On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote on log4j-dev:
> Hello,
> As you are probably aware, more and more projects are adopting the
> SLF4J API. I would venture say that SLF4J's adoption rate is roughly
> equivalent to that of log4j itself. Although the SLF4J API is not
> perfect, most SLF4J users seem to be extremely happy with it.
> Harry Metske synthesized various logging paths in JSPWiki
> https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp
> I was taken aback by the picture he paints. I think we as log4j
> committers owe it to Java developers to propose a saner logging model.
> Given the multiplicity of logging APIs in the Java world, I propose
> that log4j implement the SLF4J API directly. This can be done in the
> next version of log4j, say 1.3 or 2.0.
> Unfortunately, the adoption of the SLF4J API by log4j will be break
> 100% compatibility with existing log4j clients. More precisely,
> logging statements passing java.lang.Object as the message parameter
> will need to be changed to java.lang.String. Assuming that the
> proportion of logging statements using objects instead string is
> extremely small, comparatively few users will be affected. More
> importantly, in my experience, even very large projects can be
> migrated to the SLF4J API within half an hour.
> There is even a tool called slf4j-migrator to help with such
> migration [1].
> Is there support for my proposal?
> [1] http://www.slf4j.org/migrator.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Updated: (LOG4J2-27) log4j 2 should implement the SLF4J API
directly
Posted by "Curt Arnold (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Curt Arnold updated LOG4J2-27:
------------------------------
Attachment: jspwiki-log.pdf
PDF version of OpenOffice document referenced in mailing list post. Original appears to have been an attachment to an undisclosed JIRA issue for JSPWiki.
> log4j 2 should implement the SLF4J API directly
> -----------------------------------------------
>
> Key: LOG4J2-27
> URL: https://issues.apache.org/jira/browse/LOG4J2-27
> Project: Log4j 2
> Issue Type: Wish
> Components: API
> Reporter: Curt Arnold
> Attachments: jspwiki-log.pdf
>
>
> A PDF version of jspwiki-log.odf will be attached to this bug.
> On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote on log4j-dev:
> Hello,
> As you are probably aware, more and more projects are adopting the
> SLF4J API. I would venture say that SLF4J's adoption rate is roughly
> equivalent to that of log4j itself. Although the SLF4J API is not
> perfect, most SLF4J users seem to be extremely happy with it.
> Harry Metske synthesized various logging paths in JSPWiki
> https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp
> I was taken aback by the picture he paints. I think we as log4j
> committers owe it to Java developers to propose a saner logging model.
> Given the multiplicity of logging APIs in the Java world, I propose
> that log4j implement the SLF4J API directly. This can be done in the
> next version of log4j, say 1.3 or 2.0.
> Unfortunately, the adoption of the SLF4J API by log4j will be break
> 100% compatibility with existing log4j clients. More precisely,
> logging statements passing java.lang.Object as the message parameter
> will need to be changed to java.lang.String. Assuming that the
> proportion of logging statements using objects instead string is
> extremely small, comparatively few users will be affected. More
> importantly, in my experience, even very large projects can be
> migrated to the SLF4J API within half an hour.
> There is even a tool called slf4j-migrator to help with such
> migration [1].
> Is there support for my proposal?
> [1] http://www.slf4j.org/migrator.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org