You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/05/07 15:07:27 UTC
Re: Corner case where ServiceListener do not receive events for
matching services
Hi,
Guillaume Nodet schrieb:
>
> 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
Hmm, I fear, that in this case the framework is not able to validate the
registration and thus send events since the framework has no way of
telling which service interface (class object) is really implemented by
the factory.
As I understand it, this corner case is not properly handled in the
spec, yet I would conclude from the specification, that not sending a
ServiceEvent is correct in this case: An event is only sent if the
service providing bundle and the event listener bundle use the service
class from the same source, or specifically if
ServiceReference.isAssignableTo(Bundle, String) returns true.
Now, given the bundle providing the service (bundle C here) has no
wiring to the actual service class (R exported by bundle A) and hence
the isAssignableTo method will always return false.
Regards
Felix
>
>> 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
>>>
>
>
>
Re: Corner case where ServiceListener do not receive events for
matching services
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/7/09 9:25 AM, Stuart McCulloch wrote:
> That sounds like a question for the osgi-dev list - certainly it can't
> check
> the actual instance without breaking the laziness of service factories. It
> could perhaps check the wiring, but there may be reasons why this isn't done
> (lazy package resolution?)
>
> Or do i miss something ?
>
Service factories weren't created for purposes of laziness, they were so
the service could know who is requesting it and possibly tailor the
service for the requester.
In this case, we would have to modify our check to always eagerly get
the service object from the factory. Sort of sucks, but I don't see
another way.
-> richard
>> On Thu, May 7, 2009 at 15:07, Felix Meschberger<fm...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Guillaume Nodet schrieb:
>>>
>>>> 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
>>>>
>>> Hmm, I fear, that in this case the framework is not able to validate the
>>> registration and thus send events since the framework has no way of
>>> telling which service interface (class object) is really implemented by
>>> the factory.
>>>
>>> As I understand it, this corner case is not properly handled in the
>>> spec, yet I would conclude from the specification, that not sending a
>>> ServiceEvent is correct in this case: An event is only sent if the
>>> service providing bundle and the event listener bundle use the service
>>> class from the same source, or specifically if
>>> ServiceReference.isAssignableTo(Bundle, String) returns true.
>>>
>>> Now, given the bundle providing the service (bundle C here) has no
>>> wiring to the actual service class (R exported by bundle A) and hence
>>> the isAssignableTo method will always return false.
>>>
>>> Regards
>>> Felix
>>>
>>>
>>>>> 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
>>
>>
>
>
>
>
Re: Corner case where ServiceListener do not receive events for
matching services
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/5/7 Guillaume Nodet <gn...@gmail.com>
> So I guess in this case the registration should throw an exception.
> Currently the test is as follow:
>
> try
> {
> // Check to make sure that the service object is
> // an instance of all service classes; ignore if
> // service object is a service factory.
> if (!(svcObj instanceof ServiceFactory))
> {
> for (int i = 0; i < classNames.length; i++)
> {
> Class clazz =
> Util.loadClassUsingClass(svcObj.getClass(), classNames[i]);
> if (clazz == null)
> {
> throw new IllegalArgumentException(
> "Cannot cast service: " + classNames[i]);
> }
> else if (!clazz.isAssignableFrom(svcObj.getClass()))
> {
> throw new IllegalArgumentException(
> "Service object is not an instance of \""
> + classNames[i] + "\".");
> }
> }
> }
>
> reg = m_registry.registerService(bundle, classNames, svcObj,
> dict);
> }
>
>
> I think it should be consistent with isAssignable and reject and
> registration if the exporting bundle does not have any wire to all the
> packages of the exported classes.
>
That sounds like a question for the osgi-dev list - certainly it can't check
the actual instance without breaking the laziness of service factories. It
could perhaps check the wiring, but there may be reasons why this isn't done
(lazy package resolution?)
Or do i miss something ?
>
> On Thu, May 7, 2009 at 15:07, Felix Meschberger <fm...@gmail.com>
> wrote:
> > Hi,
> >
> > Guillaume Nodet schrieb:
> >>
> >> 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
> >
> > Hmm, I fear, that in this case the framework is not able to validate the
> > registration and thus send events since the framework has no way of
> > telling which service interface (class object) is really implemented by
> > the factory.
> >
> > As I understand it, this corner case is not properly handled in the
> > spec, yet I would conclude from the specification, that not sending a
> > ServiceEvent is correct in this case: An event is only sent if the
> > service providing bundle and the event listener bundle use the service
> > class from the same source, or specifically if
> > ServiceReference.isAssignableTo(Bundle, String) returns true.
> >
> > Now, given the bundle providing the service (bundle C here) has no
> > wiring to the actual service class (R exported by bundle A) and hence
> > the isAssignableTo method will always return false.
> >
> > Regards
> > Felix
> >
> >>
> >>> 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
>
--
Cheers, Stuart
Re: Corner case where ServiceListener do not receive events for
matching services
Posted by Guillaume Nodet <gn...@gmail.com>.
So I guess in this case the registration should throw an exception.
Currently the test is as follow:
try
{
// Check to make sure that the service object is
// an instance of all service classes; ignore if
// service object is a service factory.
if (!(svcObj instanceof ServiceFactory))
{
for (int i = 0; i < classNames.length; i++)
{
Class clazz =
Util.loadClassUsingClass(svcObj.getClass(), classNames[i]);
if (clazz == null)
{
throw new IllegalArgumentException(
"Cannot cast service: " + classNames[i]);
}
else if (!clazz.isAssignableFrom(svcObj.getClass()))
{
throw new IllegalArgumentException(
"Service object is not an instance of \""
+ classNames[i] + "\".");
}
}
}
reg = m_registry.registerService(bundle, classNames, svcObj, dict);
}
I think it should be consistent with isAssignable and reject and
registration if the exporting bundle does not have any wire to all the
packages of the exported classes.
Or do i miss something ?
On Thu, May 7, 2009 at 15:07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Guillaume Nodet schrieb:
>>
>> 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
>
> Hmm, I fear, that in this case the framework is not able to validate the
> registration and thus send events since the framework has no way of
> telling which service interface (class object) is really implemented by
> the factory.
>
> As I understand it, this corner case is not properly handled in the
> spec, yet I would conclude from the specification, that not sending a
> ServiceEvent is correct in this case: An event is only sent if the
> service providing bundle and the event listener bundle use the service
> class from the same source, or specifically if
> ServiceReference.isAssignableTo(Bundle, String) returns true.
>
> Now, given the bundle providing the service (bundle C here) has no
> wiring to the actual service class (R exported by bundle A) and hence
> the isAssignableTo method will always return false.
>
> Regards
> Felix
>
>>
>>> 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
Re: Corner case where ServiceListener do not receive events for
matching services
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/5/7 Felix Meschberger <fm...@gmail.com>
> Hi,
>
> Guillaume Nodet schrieb:
> >
> > 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
>
> Hmm, I fear, that in this case the framework is not able to validate the
> registration and thus send events since the framework has no way of
> telling which service interface (class object) is really implemented by
> the factory.
>
> As I understand it, this corner case is not properly handled in the
> spec, yet I would conclude from the specification, that not sending a
> ServiceEvent is correct in this case: An event is only sent if the
> service providing bundle and the event listener bundle use the service
> class from the same source, or specifically if
> ServiceReference.isAssignableTo(Bundle, String) returns true.
>
> Now, given the bundle providing the service (bundle C here) has no
> wiring to the actual service class (R exported by bundle A) and hence
> the isAssignableTo method will always return false.
>
yes, that's how I read the spec:
http://www.osgi.org/javadoc/r4v41/org/osgi/framework/ServiceReference.html#isAssignableTo(org.osgi.framework.Bundle,%20java.lang.String)
"For the bundle that registered the service referenced by this
ServiceReference (registrant bundle); find the source for the package. If no
source is found then return true if the registrant bundle is equal to the
specified bundle; otherwise return false."
so if C is doing the registering, but doesn't have a wire for one of the
packages then it seems only it can see the service.
btw, you can always extend AllServiceListener to listen for all service
events, regardless of class-compatibility
Regards
> Felix
>
> >
> >> 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, Stuart