On 9/3/09 11:56, Guillaume Nodet wrote:
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.
No, it doesn't need to dynamically load it, just try to use it, which
will result in an exception like a normal class load attempt...the only
difference is that it may eventually become resolved in the future.
If you were doing lots of logging, it would likely hurt performance, but
you don't have to try to load the class each time. You could devise your
logging methods to probe for the package once day, for example.
-> richard
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
