Hi Clément,
You may want to also look at
https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html
:)
- Ray
On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> Since both bundles B and C offer to export the api.a package, the
> framework
It all depends ... In general state can be managed in many different ways.
Prototype scope is too much in your face, too much boilerplate, that is why I
avoid it. It works nicely behind the scenes though like DS and CDI. I do not
think I've ever used them so far. (Which is a self perpetuating
On Wed, Mar 11, 2020 at 10:02 AM Raymond Auge
wrote:
> Prototype scope is super important. It's true we don't have a huge number
> of uses (it may be less than 1% of all services), but where you need them
> they are incredibly useful, particularly in modelling behaviours defined
> outside the
You cannot have two bundles where:
- each exports the same package (and does not import it)
- AND each exports a service for a type in said package
- AND those services are compatible
Basics of OSGi Classloading:
- each bundle is loaded in a separate classloader
- classloaders load classes (and
Prototype scope is super important. It's true we don't have a huge number
of uses (it may be less than 1% of all services), but where you need them
they are incredibly useful, particularly in modelling behaviours defined
outside the realm of OSGi.
For instance, JAX-RS expects resources to be
Hi Alain,
a little bit late but maybe some side notes to EMF and OSGi. EMF is not
thread-safe. May it be possible that you share one ResourceSet/Resource
over many Prototype instances?
This is in general not a good idea. In case you use EMF with Equinox,
you should give each prototype
Mark,
Thanks for the info. Just as a side note we are using EMF with CDO here and
I'll double check but I believe we have this correctly managed, but I'm
aware of some CME issues that can sometimes happen, even in a normal RCP
application when dealing with itemProviders for example.
Cheers,
Hi Alain,
Am 11.03.20 um 15:29 schrieb Alain Picard:
Mark,
Thanks for the info. Just as a side note we are using EMF with CDO
here and I'll double check but I believe we have this correctly
managed, but I'm aware of some CME issues that can sometimes happen,
even in a normal RCP application
> Since both bundles B and C offer to export the api.a package, the framework
> could resolve both bundles to each export the package. Thus you can end up
> with 2 exports of the api.a package in the framework. So bundle D will import
> api.a from either bundle B or bundle C and thus will not
Since both bundles B and C offer to export the api.a package, the framework could resolve both bundles to each export the package. Thus you can end up with 2 exports of the api.a package in the framework. So bundle D will import api.a from either bundle B or bundle C and thus will not be able to
Hi all,
I have some sparse service binding issues at runtime that I think are related
at how my bundles export packages.
Here is what I have:
- Bundle A exports API package api.a and is not resolvable (not present at
runtime).
- Bundle B provides api.a.Service1 service and export/import api.a
Peter and Tim,
Thanks for the pointers. The error was caused by some invalid use of a
disposed object. This was using factory components and I switched all of it
to use prototype components instead which IMHO are easier to manage.
And Peter to your question about using prototype scope, those
Thanks BJ and Ray, It's much clearer now!
Clement.
‐‐‐ Original Message ‐‐‐
On Wednesday 11 March 2020 16:45, BJ Hargrave wrote:
> If multiple bundles export the identical package (that is, the same class
> files containing the same byte codes), the runtime classes are different and
If multiple bundles export the identical package (that is, the same class files containing the same byte codes), the runtime classes are different and distinct. A Class object is a product of the class file and the class loader which loads it.
So when bundle B (exporting its copy of package
14 matches
Mail list logo
