But this means the code has to dynamically load the class, right ? Or at least try to load it each time it will log something. Wouldn't that hurt performance ? I like the idea of being able to automatically detect the log api when installed though.
On Thu, Sep 3, 2009 at 16:43, Stuart McCulloch <mccu...@gmail.com> wrote: > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
