[jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments
Scott Hasse (JIRA)
issues at jboss.org
Wed Feb 12 09:25:29 EST 2014
[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12943902#comment-12943902 ]
Scott Hasse commented on AS7-1389:
----------------------------------
Moving along to the third point in support of default visibility of third party logging APIs and implementations. I've attempted to summarize it as "The majority of users who bundle logging implementations with their applications do so by accident and you want to protect those users from their logging being broken by having their application log events written to the server log even if they bundle a logging implementation and corresponding configuration.".
There seems to be a relationship between this point and point #2, and thus my experience to date again leaves me not understanding your perspective on this point, as the vast majority of applications I've seen intentionally package both a logging implementation and configuration that they intend to be used. I will admit that I've seen way too many applications bundle extraneous platform or container APIs such as the servlet API and JAXP APIs, but I consider that a completely different issue, in that those APIs are clearly either a part of the JEE specification or Java platform, and for better or worse the third party logging APIs and implementations that JBoss is exposing are clearly a part of neither.
You have advocated (and the implementation does in fact) "just ignore whatever is packaged with the application whether it was included intentionally or not". It seems to me (and as Lars originally brought up above), this approach intentionally causes functionality that works in other container environments to not work in JBoss. Whether providing third-party logging API visibility makes an application more or less portable is a separate point, but it seems to me that the implementation as-is breaks what should be portable functionality and seems to violate the principle of least astonishment for someone who is well-versed in JEE. Specifically, servlet 3.1 spec section 10.7.2: "It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs.". I understand you would probably not categorize the JBoss-provided log4j, etc. as "container-wide library JARs" (I would be interested to understand how you categorize those jars in the context of the specifications), however I think the basic developer expectation still stands.
Especially in the case of an application packager including both their own logging implementation and configuration it seems to me their intent is clear and the container should respect it. Can you help me understand why you feel it is appropriate to override an intentionally user-packaged third party logging implementation and configuration?
The case were someone packages only the implementation and not a configuration is admittedly less clear, but in my opinion that problem should fall to the implementer of the third party logging framework that the application developer is using.
Regards,
Scott
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
> Key: AS7-1389
> URL: https://issues.jboss.org/browse/AS7-1389
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.0.0.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}.
--
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
More information about the jboss-jira
mailing list