2 Replies Latest reply on Jan 31, 2013 4:09 PM by djchapm

    JBOSGI Blueprint Class Ref in AS 7.1.3.Final

    djchapm
    djchapm Jan 18, 2013 6:08 PM

      Hi,

       

      I was playing around with OSGI and changed one of my osgi api bundle interfaces from an interface to an abstract class.  I believe this may be issue with jbosgi.. but not sure.

       

      In my blueprint config for implementation bundle it was:

       

      <reference id="echoservice" interface="com.clink.services.interfaces.EchoService"/>

       

      On deployment and then starting the bundle it throws a blueprint exception:

       

      15:35:26,552 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (Blueprint Extender: 3) Unable to start blueprint container for bundle SIExampl

      org.osgi.service.blueprint.container.ComponentDefinitionException: A class com.clink.services.interfaces.EchoService was found in the interfaces list, but class proxying is not allowed by default. The ext:proxy-method='classes' attribute needs to be added to this service reference.

       

           at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(

      AbstractServiceReferenceRecipe.java:293

      ..

       

      So I went and figured out how to follow those directions and changed my bundle to use ext:proxy-method.  So now my blueprint config shows:

       

      ext:proxy-method

      ="classes" id="echoservice"interface="com.clink.services.interfaces.EchoService"/>

      Now I get

      15:41:00,209 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (Blueprint Extender: 2) Unable to start blueprint container for bundle SIExampleService2: org.osgi.service.blueprint.container.ComponentDefinitionException: java.lang.NoSuchMethodError: org.osgi.framework.Bundle.adapt(Ljava/lang/Class;)Ljava/lang/Object;

       

      So is this incompatibility maybe with version of osgi supplied with EAP 6.0.1 / AS 7.1.3.Final?

        • 1. Re: JBOSGI Blueprint Class Ref in AS 7.1.3.Final
          ulrichromahn
          ulrichromahn Jan 31, 2013 2:43 PM (in response to djchapm)

          Daniel,

           

          I believe defining an OSGi Service as an Abstract Class will not work at all.

           

          Blueprint will be creating a dynamic proxy for each defined service and then instantiate the actual service object via reflection.

           

          So, if you are using an Interface, Blueprint will use the associated service bean to instantiate the actual service object. However, if you use proxy-method='classes', I believe it assumes that your service definition is already a concrete class and will try to instantiate this class directly.

          However, an abstract class cannot be instantiated.

           

          On a different note: I would not consider it good practice anyways to use a concrete class as service definition and not an interface.

           

          In addition, I am generally staying away from abstract classes in conjunction with any IoC container, such as Spring, CDI, or Blueprint, since those frameworks will try to control the lifecycle of Java classes which is not easily possible with abstract classes (since they cannot be directly instantiated).

           

          -Uli

            • Actions
          • 2. Re: JBOSGI Blueprint Class Ref in AS 7.1.3.Final
            djchapm
            djchapm Jan 31, 2013 4:09 PM (in response to ulrichromahn)

            Thanks Uli for your response.  Regarding Abstract Classes... I'm finding it hard to design w/out them in a meaningful way.  I've been using Spring since Spring 1.0 for service layer abstraction and IOC/DI.  I am able to use abstact classes to do common coding and abstract methods for custom needs.  So I can handle all my services in the same way (Think Command Pattern).

             

            Anyway - I made it work by creating more modules.

            Mod1:

              BaseInterface

            Mod2:

              ServiceInterface extends BaseIinterface

              -> This is the interface that is exported for clients

            Mod3:

              Abstract class implements BaseInterface

              {

                pub final invoke (String msg, Object[] params) {

                   Command pattern:

                   doThis(msg, parms); doThat; etc();

                }

                pub abstract doThis(String msg, Object[] params);

              }

             

            Mod 4:

              ServiceImplementation extends AbstractClass implements ServiceInterface.

             

            So now I can have classes that work on AbstractClass and fulfill a need common to all services.  And the code is in one spot, not 100.

            I'm sure you could create Utils or something to handle that invoke method, but I prefer this composition.  Functionality is more built in.

             

            I'm fairly new still to OSGI so not adverse to advice.  But I don't think I'm breaking any rules.  Haven't been able to find any great SOA Patterns for OSGI So far - would be great to see that on an OO level.

             

            Dan C.

              • Actions