Equinox behaves the same as Felix here.

Personally I find the term "not incompatible" hard to understand in section
5.9.1.  Seem "not incompatible" is just "compatible".

Section 6.1.23.6 is the JavaDoc for isAssignableTo() but I don't think it
necessarily reflects the intent of section 5.9.1.  By "last sentence" I
assume you mean the sentence in 5.9.1 "That is, it is either wired to the
same source
class loader or it has no wire for that package at all.".  For the case
where the consuming bundle is not wired to the package at all it is
"compatible" with the service because it can never cast that service to the
service type.  The point of this method is to avoid ClassCastExceptions in
the consuming bundle.  As Richard points out we assume reflection is being
used if the consuming bundle is not wired to the package of the service
class.

Tom




|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"Alan D. Cabrera" <[email protected]>                                     
                                                                      |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSGi Developer Mail List <[email protected]>                            
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |04/14/2009 10:26 PM                                                          
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [osgi-dev] isAssignableTo() and the system bundle                        
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|





The JavaDoc reflects section 6.1.23.6 and more accurately reflects the
intent of section 5.9.1.  That last sentence, to my mind, is just plain
inaccurate and dangerous.


Regards,
Alan

On Apr 14, 2009, at 8:13 PM, Richard S. Hall wrote:

      Maybe the JavaDoc needs to be updated to more closely resemble the
      spec text.

      -> richard

      On 4/14/09 10:44 PM, Stuart McCulloch wrote:
            2009/4/15 Richard S. Hall <[email protected]>
              I think you are not correct.

              If a bundle has no wire to the package, which system bundle
              shouldn't since it cannot import, then it should get back all
              service references. I think the spec assumes you are using
              reflection if you have no wire to the package. I cannot
              remember if this behavior is spec'ed some place but I thought
              so. At least that's what we do in Felix (and Equinox, I
              believe).

            ah... 5.9.1 of the core spec:

              "The service registry must therefore ensure that bundles can
            only see services that are not
               incompatible with them. A service is not incompatible with
            the bundle getting the service when
               that bundle is not wired to another source class loader for
            this interface package than the
               bundle registering the service. That is, it is either wired
            to the same source class loader or
               it has no wire for that package at all."

            but I think Alan has a point that if you read the javadoc for
            ServiceReference.isAssignableTo()
            it does seem to apply a stronger rule: that is it returns true
            if both bundles use the same source
            for the package, otherwise false

            so if the bundle providing the service has a wire, and the
            bundle using the service doesn't have
            a wire, does that mean they use the "same source" for the
            package? (isAssignableTo() == true)

              -> richard.

              On 4/14/09 8:09 PM, Alan D. Cabrera wrote:
               After reading the core spec it seems that if I look for
               service using the system bundle context, I will never be
               able to find any application specific service.  Let me
               explain my reasoning and maybe someone can show me where my
               disconnect is occurring.

               Upon reading the definition of the getServiceReferences()
               method I see that isAssignableTo() must be called with all
               the service interfaces and the bundle that is being used to
               perform the "call" to getServiceReferences().

               It seems to me that if I pass the system bundle to
               isAssignableTo() I will get false for just about all the
               application specific service interfaces.

               If that is true then it seems that I will not be able to
               retrieve most service references with the system bundle.

               Am I correct?


               Regards,
               Alan


               _______________________________________________
               OSGi Developer Mail List
               [email protected]
               https://mail.osgi.org/mailman/listinfo/osgi-dev
              _______________________________________________
              OSGi Developer Mail List
              [email protected]
              https://mail.osgi.org/mailman/listinfo/osgi-dev



            --
            Cheers, Stuart

            _______________________________________________
            OSGi Developer Mail List
            [email protected]
            https://mail.osgi.org/mailman/listinfo/osgi-dev
      _______________________________________________
      OSGi Developer Mail List
      [email protected]
      https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to