[
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:
------------------------------------------
Hello,
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: [email protected]
For additional commands, e-mail: [email protected]
