2009/5/7 Guillaume Nodet <[email protected]>

> 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 <[email protected]>
> 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

Reply via email to