Hi,
Am Donnerstag, den 17.02.2011, 11:59 + schrieb Neil Bartlett:
Depending on the DS implementation you may be able to introspect the
state of the components, including the ones that are unsatisfied, and
report this as a kind of startup progress. Felix DS has a handy
introspection API
I think we have think a bit deeper. Assume you have 2 exporters of IFoo that
are both compatible with the proxy you generate. Shouldn't you create a proxy
for both?
I think the only viable solution is to register the proxy with each distinct
exporter of IFoo's package for which you're
On Mon, Feb 21, 2011 at 10:49 AM, Peter Kriens peter.kri...@aqute.biz wrote:
I think we have think a bit deeper. Assume you have 2 exporters of IFoo that
are both compatible with the proxy you generate. Shouldn't you create a proxy
for both?
Ideally yes, but this doesn't seem to be
On 21.02.2011 12:19, Neil Bartlett wrote:
On Mon, Feb 21, 2011 at 10:49 AM, Peter Kriens
peter.kri...@aqute.biz wrote:
I think we have think a bit deeper. Assume you have 2 exporters of
IFoo that are both compatible with the proxy you generate.
Shouldn't you create a proxy for both?
Scott Lewis wrote:
Are there any viable approaches other than this? e.g. can the wiring
of the RSA (or TopologyManager) bundle be dynamically manipulated...to
allow the RSA or TM itself to register the proxy service factory?
I'm not sure this would work (someone else should confirm) or even
Did some deeper digging and I think we have an interesting issue.
ECF RSA should work with +M3 release of 3.7 Equinox. It turns out that a bug
requested by Guillaume Nodet relaxed the rules for Service Factory services. If
the registrant of the service cannot see the package for any of the
Yes, I recall this issue and that was the same kind of problem where
blueprint had to register a proxy on behalf of a bundle, so the
classloader of the actual service factory could not see the service
interface directly. With the use of extenders, it seems like a more
and more common use cases.
Hi Peter,
Although I'm very happy to hear this, I've been running/testing on 3.7M4
version of Equinox and I'm still seeing the problem (i.e. proxy
ServiceFactory registered by TM bundle...without dynamic
import:*...still doesn't pass compatibility check).
Maybe I need to do something else
I am 99% certain Felix and Equinox behave the same WRT factories. Richard and I spent a lot of time discussing this issue brought up by Guillaume and we are pretty sure both frameworks behave the same here. If the registrant bundle does not have access to the package the service is being
https://bugs.eclipse.org/bugs/show_bug.cgi?id=326918I just looked at the code again. It should work as long as the registrant bundle has no wire to the package in question AND the service was registered using a ServiceFactory. If you are seeing something else, please open an equinox
Peter is correct. If bundleTM defines the service factory impl class and
uses its own context to register the service, then the framework considers
it a private service for use only by the registering bundle.
If you add a 4th bundle (bundleProxy), then bundleTM can use bundleProxy's
context to
Peter
A very cheap way to do what I want is to let the VM just throw some
runtime exception on any object that is from a stale class loader.
You make it all sound so easy. :-)
If you mean throw some runtime exception on any *access to* object that
is from a stale class loader then you are
12 matches
Mail list logo
