Hello Christian, thanks for the detailed explanation. I will forward this to commons ML so that the others can discuss about this.
Regarding splitting the library into several packages/jars/bundles: This would require a new major release. We are still evaluating if this makes sense since there are good alternatives. 1.1.2 was intended to fix bugs only. Regards, Benedikt 2013/2/23 Christian Schneider <ch...@die-schneider.net> > I was not aware that the commons projects already use the bundle plugin. > > I think the main question is what we want to achieve with making the > commons logging jars bundles. At the time I created the issue I did not > know about pax logging. So I was looking for a way to simply use commons > logging in OSGi. Now with pax logging this not necessary. I can depend > on commons logging api in my project and at deployment simply install > pax logging instead. So the immediate need of doing logging is already > fullfilled this way. > > If the goal is to fully use commons logging wihout pax logging in OSGi > then it is a lot harder than just creating bundles. In this case we > would have to support two other features: > 1. Getting/Creating a logger. If a user bundle only imports the API > packages then it will have no access to the impl classes. Still > |LogFactory.getLog()| has to provide the logger in some way. In pure > OSGi the logger factory would be an OSGi > service. As commons logging also has to work outside OSGi this is not > possible. So I am not sure how to support this. > 2. Loading config. The logging config should be provided in a central > place. The default way in OSGi would be to use the config admin service. > > As both these features are already provided by pax logging I am not sure > how much sense it would make to also implement them in commons logging. > > Btw. one problem with the commons logging API like with many other > logging APIs is that the LogFactory.getLog() is part of the API but also > needs access to the impl. So this is no clean API where this dependency > should not be present. > > Christian > > On 23.02.2013 13:29, Benedikt Ritter wrote: > > Hi, > > > > thanks for your help. Commons already has the bundle plugin in it's > parent > > pom. Several properties can be used to configure it. We can extract the > > correct configuration from your patch, thanks for that! You asked why > there > > are three jars created. I think is for historical reaons. Explanation can > > be found on JCL website [1]. > > > > There are two things I currently don't understand: > > - the rebundled versions of JCL I have seen export the impl package. I > > don't see why this is necessary. Users should only depend on the API > > defined in o.a.c.logging package. > > - the rebundled version from SpringSource uses the "uses" directive for > the > > optional dependencies [2]. IIUC this is only required if a bundle passes > > types from packages through its external API [3]. In other words: we > should > > define a uses relationship to log4j if our external API hands log4j types > > to users. But it doesn't so, what's the point of the uses directive in > the > > rebundled JCL from SpringSource? > > > > Thanks a lot for your help! > > Benedikt > > > > [1] http://commons.apache.org/logging/guide.html#Jars Included in the > > Standard Distribution > > [2] http://ebr.springsource.com/**repository/app/bundle/version/** > > detail?name=com.springsource.**org.apache.commons.logging&** > > version=1.1.1&searchType=**bundlesByName&searchQuery=**logging< > http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging > > > > [3] > > > http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/ > > > > > > 2013/2/23 Christian Schneider <ch...@die-schneider.net> > > > >> I have created a patch to add the maven bundle plugin to the pom. You > can > >> find it in the jira issue. > >> While the headers look good then I am not sure if this is enough to > really > >> use commons logging in OSGi. > >> > >> I typically use pax logging for logging in OSGi. It already supports all > >> big logging APIs including commons logging and makes sure they can also > be > >> configured using a log4j config file. > >> So as there is a nice solution I am not sure how much we should invest > to > >> make commons logging working standalone. On the other hand if the > commons > >> logging API jar is a bundle then perhaps the commons logging > >> api can be removed from pax logging and just deployed as a bundle. > >> > >> Christian > >> > >> Am 22.02.2013 20:22, schrieb Benedikt Ritter: > >> > >> Hi Felix community, > >>> we are trying to fix our OSGi manifest information for o.a.c.logging as > >>> requested in Jira [1]. We don't know yet how a correct manifest for > >>> [logging] would look like. We have looked at rebundled versions from > felix > >>> and spring [2]. > >>> Can someone join our ML and help out a bit? Here [3] is what we have > found > >>> out so far :-) > >>> > >>> TIA! > >>> Benedikt > >>> > >>> [1] https://issues.apache.org/**jira/browse/LOGGING-124< > https://issues.apache.org/jira/browse/LOGGING-124> > >>> [2] > >>> http://ebr.springsource.com/**repository/app/bundle/version/** > >>> detail?name=com.springsource.**org.apache.commons.logging&** > >>> version=1.1.1&searchType=**bundlesByName&searchQuery=**logging< > http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging > > > >>> [3] http://markmail.org/message/**277c5mrpdpcfj4wr< > http://markmail.org/message/277c5mrpdpcfj4wr> > >>> > >> > >> -- > >> Christian Schneider > >> http://www.liquid-reality.de > >> > >> Open Source Architect > >> Talend Application Integration Division http://www.talend.com > >> > >> > > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
