Rant aside...
This is what I am saying all along... Bundles are not good candidates
for codebase annotations.
For exactly the reason you describe: bundles represent a template that
may produce different wirings.
But to recreate an object graph you need the _wiring_ - not the template.
And this is also why any kind of statically (ie. at bundle build time)
locking of the dependencies is not going to work either.
The ImplementationDetailServiceProxy runtime dependencies are not yet
known when creating the bundle manifest
since its interface to be useful must be resolved in each client
environment differently (or all parties in the distributed system
must share the same versions of the code - which makes the whole point
of OSGI moot)
The only way I can see around this is not to treat jar files downloaded
dynamically as bundles
but rather create fake bundles from them and generate artificial
manifests based on information in the stream.
Kind of an ugly hack really...
The situation might change if OSGI defined a way to provide bundle
manifest not as a statically prepared MANIFEST.MF
inside the jar file but as separate piece of information provided
dynamically at runtime.
A little rant now...
This container centric view is IMHO quite restricting.
There is no reason why resolution of code dependencies (aka preparing
the wiring)
must be done by the particular container where the client software is
executed.
It might as well be done somewhere else (ie. in the service provider
environment)
and sent to the client already prepared for execution.
OSGI way is not the only way.
I do not find any particular problem with downloading data together with
the code that manipulates this data.
I am doing it very often when viewing tens (if not more) of web sites daily.
Haven't found any major issues with that - quite the opposite - it seems
like this is a pretty damn good way of doing things.
End of rant...
Thanks,
Michal
Niclas Hedhman wrote:
As I think you know, the whole purpose of OSGi is to NOT tie the resolution
to Bundles, but to explicitly Exported (with versions) packages. If people
screw up and don't declare the Import/Export package meta data correctly,
then ordinary OSGi may fail just as spectacularly. The difference being
that Java serialization is slightly more sensitive to class changes than
the code itself, and that was an issue from the start. "Back then" it was
quickly realized that "long-term" storage of serialized state was a bad
idea, but "long-term" is relative to code releases and with highly
distributed systems, this is now a reality in networked applications as
well as storing serialized objects to disk. With that in mind, one should
seriously reconsider the status of Java Serialization in one's application,
realize that every serialized class, incl possible exceptions, is a
published API and needs to be treated as such, just as a REST API, SOAP
interface or HTTP itself. Sorry for the rant...
Back to OSGi; even if you really need to tie a class to a particular
bundle, you can do that with attributes and the 'mandatory' directive.
Cheers
Niclas
On Wed, Feb 1, 2017 at 3:29 AM, Michał Kłeczek<michal.klec...@xpro.biz>
wrote:
Unfortunately it is
