2009/9/3 Guillaume Nodet <gno...@gmail.com> > 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. >
yes I'm not talking about exporting it, I totally agree FileInstall doesn't need the export I'm talking about the difference between: Import-Package: org.osgi.service.log;resolution:=optional and: DynamicImport-Package: org.osgi.service.log the former means a "one-time" check when the bundle resolves, the latter will continue to check on each request until the import can be satisfied (and then won't recheck until the bundle is refreshed) so for the optional import case, if I install and resolve FileInstall on a system without the LogService API, then I install and resolve a logger (along with the compendium API) then I don't believe FileInstall will see the logger unless it's refreshed whereas with the dynamic import, it would be able to pick up the newly installed logger > 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 > -- Cheers, Stuart
