[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- You seem to be quick to give up a good discussion with an ad hominem attack just when I felt I was going to learn something. To clarify my comment with respect to "common sense", it specifically referred to limiting classloader visibility, and I think the basic point still stands. That said, my motivations are to have the JBoss EAP be the best container it can be to that end I think we should try and put the best case forward from all perspectives. I'll be honest that I don't really understand your viewpoint very well. I'll attempt to represent it as best I can and perhaps you can tell me where I've got it incomplete or wrong. Based on your comments above my impression of your viewpoint is: JBoss EAP should continue to by default provide classloader visibility of log4j, slf4j and commons logging implementations to JEE application deployments because: 1) That is the way it is currently done in EAP 6. Also in EAP 5 and 4 default visibility to log4j and commons logging (and later slf4j) were provided. As a result there are many applications deployed that already use the container-provided logger implementations. Those applications would need to define an explicit dependency in order to have their logging work properly if the default were changed. 2) 99% of the time users want to have centralized logging (that is, application-level logging interleaved with container logging), and a container-provided logging implementation is the cleanest way to do that. 3) 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. 4) Packaging a logging implementation and configuration with your application is not portable behavior. Using container-provided logging implementations is more portable. 5) JBoss EAP is more than just a JEE container. It provides many additional facilities to JEE applications above and beyond the spec and log4j, slf4j and commons logging implementations are good examples of that sort of value-added functionality. 6) The spec does not limit what additional facilities can be provided and it is good for container vendors to go above and beyond the JEE specified APIs and their corresponding implementations to provide visibility to additional third-party APIs and implementations by default, specifically in this case third-party logging implementations. 7) It is relatively simple to disable the default visibility and it will be getting even simpler in the future. 8) This is all subjective preference anyway and the reasons for changing are not convincing enough. Again, my interest is to understand your position as well as I can so if I'm misrepresenting anything or leaving anything out, please do correct me. Regards, Scott -- 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