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
