felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: OSGi manifest information for org.apache.commons.logging
Date Sat, 23 Feb 2013 15:24:16 GMT
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.


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 <chris@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

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message