On Thu, Sep 3, 2009 at 16:06, Stuart McCulloch <mccu...@gmail.com> wrote:
> 2009/9/3 Guillaume Nodet <gno...@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-...@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
