felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: OSGi manifest information for org.apache.commons.logging
Date Sat, 23 Feb 2013 16:50:18 GMT
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 <chris@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 <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
> 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

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