NJB Given that there is no way to take an object away from someone who has a
reference to the object, the service contract should state the behavior of
the object outside of its defined life time.
I remember a conversation with Peter a few years ago where Peter was
wondering whether it would
First a little background
ServiceTracker has two open methods:
public void open(boolean trackAllServices) and public void open()
(which calls open(false))
The javadocs for trackAllServices is:
* @param trackAllServices If {@code true}, then this
*{@code ServiceTracker}
Hi Scott,
Replies inline.
On Sun, Feb 20, 2011 at 3:58 PM, Scott Lewis sle...@composent.com wrote:
First a little background
ServiceTracker has two open methods:
public void open(boolean trackAllServices) and public void open() (which
calls open(false))
The javadocs for
Hi Neil,
On 2/20/2011 1:14 PM, Neil Bartlett wrote:
stuff deleted
If you are only seeing the proxy services when calling
ServiceTracker.open(true), then it suggests something is going wrong.
It sounds like a bug either in your code or in the framework's
compatibility checking.
Thanks for the
On 2/20/2011 3:15 PM, BJ Hargrave wrote:
The framework does not care about the implementation class of a
service object. Just the type names under which the service is
registered (which are usually interfaces). Class space consistency
requires the bundle registering the service (more
On 2/20/2011 4:08 PM, Scott Lewis wrote:
On 2/20/2011 3:15 PM, BJ Hargrave wrote:stuff deleted
What we are currently doing to solve this (which is hinted at in
122.5.6) is to register a ServiceFactory for proxy creation...and then
when a given client bundle first requests access to a proxy,
What we are currently doing to solve this (which is hinted at in
122.5.6) is to register a ServiceFactory for proxy creation...and
then when a given client bundle first requests access to a proxy,
the ServiceFactory.getService method is called by the framework...i.e.
public Object
What we are currently doing to solve this (which is hinted at in
122.5.6) is to register a ServiceFactory for proxy creation...and
then when a given client bundle first requests access to a proxy,
the ServiceFactory.getService method is called by the framework...i.e.
Could our problem be
On 2/20/2011 5:03 PM, BJ Hargrave wrote:
What we are currently doing to solve this (which is hinted at in
122.5.6) is to register a ServiceFactory for proxy creation...and
then when a given client bundle first requests access to a proxy,
the ServiceFactory.getService method is called by the
That is only about creating the actual service object and of course
it must implement the exact service type.
But while the framework cares about that, it also cares about the
bundle whose context was used to register the service. Does that
bundle have visibility to the exact service
In the case of RSA's registration of a ServiceFactory (for creating
proxies of a remote service), the service type (Class) is not even
loaded. It's only actually loaded when the
ServiceFactory.getService(Bundle...) is called later. So in this
case, how can the framework compare the
Hi Neil,
On 2/20/2011 6:10 PM, Neil Bartlett wrote:
Taking a step back because I'm getting confused... it seems the
problem might be as follows.
You (an RSA bundle) want to proxy the org.foo.IFoo, so you need
register your service factory against the interface name
org.foo.IFoo. You can't
On 2/20/2011 6:14 PM, BJ Hargrave wrote:
stuff deleted
You could use dynamic import package but that has some drawbacks.
First you would need to actually load the type(s) to force the
framework to establish the wires before you register the service.
Second, you could only support one
13 matches
Mail list logo
