On 5/13/09 2:21 AM, Guillaume Nodet wrote:
Actually, I think loading the class is a very bad idea.
I know the lazy activation policy has not been implemented, but it
would be, loading the class at this point would trigger the bundle and
would kinda break the lazy activation policy.
I think the only right way is to use the wires between the bundle to
check if the class is compatible.
That's the issue. If there were wires we wouldn't need to load the
class, since we use the wires first if they exist. I commented on this here:
https://issues.apache.org/jira/browse/FELIX-1131
-> richard
2009/5/7 Karl Pauls<[email protected]>:
I guess the idea behind the way we currently do things is that we want
to be lazy. If we would check on the class of the object created by
the service factory we might trigger unnecessary service creations.
However, your case might force us to do that unless we can find a
smart way to figure out this information by looking at the wiring of
the bundles. From your description I doubt that this is possible but
we probably have to think about it.
Definitely sounds to me that you should create a JIRA issue and maybe
attach your example.
regards,
Karl
On Thu, May 7, 2009 at 1:49 PM, Guillaume Nodet<[email protected]> wrote:
On Thu, May 7, 2009 at 13:41, Felix Meschberger<[email protected]> wrote:
Hi,
I am bit confused, too ;-)
Guillaume Nodet schrieb:
I've just finished debugging a corner case in karaf where a
ServiceListener did not receive events when a matching service was
registered.
The problem is not very simple:
* the service is exposed via a ServiceFactory
So, the ServiceFactory must create objects implementing the service
interface, right ?
* the service factory does not belong to the same classloader as
the interface of the exposed service
No problem. In case the factory and service interface are in different
bundles, this is expected.
* the bundle exporting the service does not have a direct import on
the interface exposed
You mean, the bundle registering the ServiceFactory ?
In this case, I would assume, this is an invalid service registration,
since the registering bundle does not know about the service interface,
unless the service interface is contained in the same bundle as the
ServiceFactory implementation.
This leads to the suspicion, that there are two actual service interface
class objects: The public one used by the listener and another one
(exported or not) used by the ServiceFactory implementation.
Or are there three bundles ? (1) exporting the service interface, (2)
exporting the service implementation and (3) registering the
ServiceFactory as a service for the service interface defined by (1) and
creating implementations located in (2) ?
Or, maybe, I am completely wrong ....
In my case, the bundle exporting the service defines a class that
indirectly implement the required interface by inheriting a class from
another package.
So I have 3 bundles:
* bundle A defines an interface R and a class S in different
packages, whith S implementing R
* bundle B defines a class T extending S, it has an import statement
on S package, but not on R package
* bundle C defines a ServiceFactory that export T service without
any import on any package from R, S, T
Maybe the service registration is invalid because bundle B does not
import R package, but the service actually implement the right
interface
Regards
Felix
This leads to the service listener not being invoked because
Util.isServiceAssignable() returns false.
I think it's a problem, but I've no idea how to solve it. The only
way I can think about is to actually check the service class returned
by the factory instead of the factory, but it may cause side effects,
not sure.
Thoughts?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Karl Pauls
[email protected]
