felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Packages exported by fileinstall
Date Thu, 03 Sep 2009 14:25:15 GMT
On Thu, Sep 3, 2009 at 16:06, Stuart McCulloch <mcculls@gmail.com> wrote:

> 2009/9/3 Guillaume Nodet <gnodet@gmail.com>
>
> > Fileinstall exports the org.osgi.service.cm and org.osgi.service.log
> > packages.
> > I wonder if this would make more sense to make them optional import and
> > make
> > sure the code can run if those are not wired.
> >
>
> yep, this comes down to whether you should package the API with the bundle
> or not
> ( and as Richard says FileInstall doesn't implement the API, so no need to
> export it )
>
>   http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg00097.html
>
> for an optional dependency it can make sense to use an optional import -
> although
> it does then make the code a little bit more involved, as your recent
> commit
> shows
>


> you should also remember optional imports are only checked *once* at
> resolution
>
> for example, if I start the FileInstall bundle without the LogService API
> available and
> only later on install a logger, then FileInstall won't pick up this service
> until its bundle
> is refreshed


But if fileinstall exports the package, then you install a log service, the
log service will be wired to fileinstall if it has the same api, which means
if you later uninstall fileinstall, the log service need to be refreshed.
And if the log service implements a higher version of the api, the
fileinstall won't be able to use it either because it already exports its
own package and you have to refresh anyway.
So in all cases, I think you need to refresh at some point, unless the
service is really optional and it does not really matter so much if it is
imported or not, which is the case here.


> ( to handle this use-case you would need DynamicImport-Package
> )
>


Or retrieve the service and use introspection to call it, which is quite
ugly too.


>
> As a side effect would also reduce the size of the jar and simplify the
> > resolution process (I don't having having bundles exporting the same
> > package
> > really helps ...)
> >
>
> well some people will want to bundle APIs with their implementations
> (potentially one
> less bundle to manage) and in this case exporting+importing the API makes
> sense
>

Right, and that's what most of our services do afaik.


>
> most of the performance issues I've seen wrt. resolution have been from bad
> APIs
> which have lots of uses constraints - I think that's more of a problem to
> be
> honest
>
> Thoughts ?
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Cheers, Stuart
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

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