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
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,
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
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
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
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
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
Some remarks:
* Yes, it is thread safe. In OSGi we mark all thread safe types with the
@ThreadSafe annotation.
* The error message is not in the log you listed. Since the log contains a
deactivation message, I hope you're handling the case corrected that you're
being called after deactivation?
Question: The method getDiagnosticForEObject can be called by different
threads. Can this be the source of the issue? I see that
ComponentServiceObject is tagged as ThreadSafe, but?
Alain
On Mon, Mar 2, 2020 at 5:47 AM Alain Picard wrote:
> Tim,
>
> I don't think so. BaValidationManagerExt is
Tim,
I don't think so. BaValidationManagerExt is used in only 1 place and it is
instantiated in activate and released in deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
Hi Alain,
Is it possible that someone has a reference to a BaValidationManagerExt service
instance that they aren’t releasing after ungetting it (or that they’re holding
onto after it has been unregistered)? It might be an SCR bug, but it’s more
likely to be some code holding onto a component
Hi
I am having a very intermittent issue with getService on a prototype
component. This is called hundreds of times and I put a breakpoint a few
weeks ago and have now gotten the error.
I have this class:
@Component(scope=ServiceScope.PROTOTYPE,
property=
12 matches
Mail list logo
