logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastian Oerding (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-235) Dependency on tools.jar and jconsole
Date Fri, 03 May 2013 06:10:16 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648212#comment-13648212

Sebastian Oerding commented on LOG4J2-235:


actually our use case IS a commercial application running on a server (but not packaged as
a WAR). Hence we could define a JDK as system requirements. However currently a JRE is sufficient
and to formulate a requirement for a JDK instead just due to two transitive dependencies that
are actually not needed makes me feeling uncomfortable.

Besides just feeling uncomfortable I totally agree with Nick Williams (class path pollution
/ usage of classes that are not intended to be used by someone just using log4j2).

About the runtime/compile time dependencies: The scopes of dependencies form a hierarchy.
Thus a Nick stated a jar that is required for compilation is also required at runtime.

You can try the following: Take a jar with a transitive dependency for example on log4j (1.2).
Then use the Maven mechanism to exclude transitive dependencies. However you may have a project
with several jars depending on log4j. Then exclude all transitive dependencies for log4j and
remove the declared direct dependency on log4j if there is any. Once the last dependency is
left you'll run into problems.

For example in Eclipse you would at first get errors such as "Class XYZ is missing. It is
indirectly referenced by some .class files" (I do not have the exact wording in my mind at
this moment). Furthermore your auto completion would fail on any of these log4j classes.

Howver everything starts to get more complex if using reflection. By reflection you may call
classes at runtime given by strings (class names) => no compile time dependency but runtime
dependency. At the moment I'm not totally sure if it can go the other way round.
I don't think so cause at some point you must call a specific class if you want to use it
otherwise there should be no dependency at all. But using service provider frameworks or using
the JDK 6 compiler API (you can give a string at runtime and compile it to a Java class ...)
or doing your own code instrumentation things are getting rather complex. Thus having removed
the dependency on tools.jar and do not encountering any compilation issues is not a real proof
(however it might be good enough as there will be some testing / continous integration before
a release).

This leads to my conclusion: If there is a transitive dependency on something, I may exclude
it and everything may compile fine. Furthermore everything may run fine for some time but
may crash at one point when a specific class is invoked using reflection. Having there no
transitive dependency gives a me kind of safety and avoids me spending time on wondering issues
that might be irrelevant.
> Dependency on tools.jar and jconsole
> ------------------------------------
>                 Key: LOG4J2-235
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-235
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0-beta5
>         Environment: Windows 7, 64 bit, Maven 3.0.5, Java 1.6
>            Reporter: Sebastian Oerding
> Hello,
> when switching from 2.0-beta4 to 2.0-beta5 I something irritating that in the dependency
hierarchy of my project. For log4j2-core there were transitive dependencies on tools.jar and
jsconsole which had not been there.
> This looks like a bug and an as a consequence requires a JDK instead of  a JRE (at least
due to the tools.jar which does not exist in Java 1.6 JRE). If these dependencies are really
required, it should be clearly stated.

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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message