felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: SCR and compendium services
Date Wed, 09 May 2007 17:04:15 GMT
Hi all,

Thanks for the feedback.

Probably, I will not include the service.log package as I will the
service.cm package. Regarding the log package, scr is really only a client,
that is, it uses the LogService class (and not more) of that package. We
could of course document, that scr only exports the service.log package to
have it handy for logging, but actually, I do not particularly like
exporting interfaces from a bundle, which does not provide an implementation
(and which does not "define" the service for a third party to implement).
SCR is simply a client of the log service.

As for the cm package, the situation is more complicated as scr has an
implementation of an interface in the cm package (namely
ManagedServiceFactory). So, in fact inclusion in case of ConfigAdmin absence
is probably a must.

Regards
Felix

On 5/9/07, heavy@ungoverned.org <heavy@ungoverned.org> wrote:
>
> >Richard S. Hall a écrit :
> >> Clement Escoffier wrote:
> >>> Hello
> >>>
> >>> Felix Meschberger a écrit :
> >>>> Hi Richard,
> >>>>
> >>>> In Felix-277 you propose to "privatize" the ServiceTracker and make
> the
> >>>> LogService package a dynamic dependency. I think, this is a good
> >>>> idea and
> >>>> will, as noted in the issue, implement this.
> >>>>
> >>>> While doing this, there is another Compendium Service dependency in
> >>>> the scr:
> >>>> Configuration Admin Service. This is a more complicated dependency
> >>>> because
> >>>> scr does not only call into the ConfigurationAdmin service but also
> >>>> registers a ManagedServiceFactory for factory components. So, if the
> >>>> OSGi cm
> >>>> packages are not available, factory components will not work (and
> >>>> configuration retrieval by other components may fail).
> >>>>
> >>>> What do you think of having scr export and re-import the OSGi cm
> >>>> package ?
> >>>> This way, the framework would select the cm package to which other
> >>>> bundles
> >>>> get wired and scr will have the OSGi cm packages regardless of
> >>>> whether a CM
> >>>> implementation exporting it is available.
> >>> It is what I do for the Log service and the Config Admin in iPOJO. It
> >>> increase the size of the bundle but I did not find another acceptable
> >>> solution.
> >>> The pom file contains folowing BND instructions:
> >>> <Import-Package>
> >>>              org.osgi.framework; version="1.3",
> >>>              org.osgi.service.cm; version="1.2",
> >>>              org.osgi.service.log; version="1.3"
> >>> </Import-Package>
> >>> <Export-Package>
> >>>              org.apache.felix.ipojo; version="0.7.1",
> >>>                ....... (some other iPOJO packages) .....
> >>>              org.osgi.service.cm; version="1.2",
> >>>              org.osgi.service.log; version="1.3"
> >>> </Export-Package>
> >>
> >> Shouldn't BND automatically detect the versions for you from the
> >> packageinfo files?
> >BND inserts versions for imported (and re-exported version), but does
> >not add version for non imported packages (In the previous snippet, BND
> >can add 1.3 and 1.2 version but cannot discover 0.7.1 version).
>
> Well, you could add a packageinfo file to your iPOJO directories too, then
> BND will automatically "discover" the version of iPOJO packages too as far
> as I understand it.
>
> But at a minimum, you can simplify your pom by removing the versions from
> the cm and log packages, since they do have packageinfo files, so they
> should be detected properly.
>
> -> richard
>

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