[
https://issues.apache.org/jira/browse/LOG4J2-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656110#comment-13656110
]
Timothy Ward commented on LOG4J2-10:
------------------------------------
I've looked at the log4j2 api and core bundles.
The api bundle looks good. The packages are all exported (which is fine for an
API bundle) and all of the exports have versions with sensible numbers. There
are no imports, which will make the API bundle very easy to reuse.
The core bundle has a few more issues. As [~pedro.lamarao] pointed out above,
the log4j core jar adds lots of dependencies. There are several issues:
1. The core bundle exports every single one of its packages. Are all of these
classes public API? Any classes that aren't intended for public use should not
be exported from the bundle.
2. None of the package imports are versioned - this makes it very difficult to
work out what else should be installed, and can cause significant compatibility
problems
3.The package imports are all mandatory, even though most users will not need
any of the function. Things like lmax disruptor and javax jms are good examples
of this. If I just want a standard RollingFileAppender then I shouldn't have to
install things like Mongo or JPA.
The first of these sets off lots of alarm bells, but as I'm not an expert in
the log4j API (other than as a user of it!) I'm not really able to tell you any
specific actions. It may be that all of those classes really are public API, in
which case the existing packaging is right.
The second of these is reasonably easy to fix as the maven bundle plugin scans
any dependencies for OSGi version information and adds it automatically.
Unfortunately the log4j2 build sets
<excludeDependencies>true</excludeDependencies> in the maven bundle plugin
configuration. This means that none of the dependency information is available
when constructing the manifest. If you change this property and make sure that
your dependencies are already OSGi bundles (for example, version 1.1.1 of the
JMS 1.1. API from Geronimo is an OSGi bundle) then the maven bundle plugin will
automatically fill in that information for you. You can then manually fix up
anything that's left. One thing to note is that you may also need to tweak the
export package/private package statements for your bundles to avoid pulling
additional code into your bundle.
The third of these indicates that the scope of the log4j core bundle is too
big. It should be reasonably easy to break off bundles for the core.jpa,
core.async, core.nosql.mongo, core.nosql.couch etc. By packaing these
separately you can make it much easier to consume the log4j core bundle without
dragging in the whole of the dependency tree. This is preferable to optional
imports, as it prevents you from having to debug unpleasant
NoClassDefFoundErrors at runtime.
> log4j 2.0 should work well with OSGi and Apache Felix
> -----------------------------------------------------
>
> Key: LOG4J2-10
> URL: https://issues.apache.org/jira/browse/LOG4J2-10
> Project: Log4j 2
> Issue Type: Wish
> Reporter: Curt Arnold
>
> OSGi and specifically the Apache Felix implementation should be considered
> for framework services such as internal logging and configuration.
> log4j 2.0 should be able to be a provider of OSGi logging services.
> OSGi package visibility declarations should be used to distinguish between
> exported and explicitly supported APIs and implementation specific details.
--
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]
