[
https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s...
]
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