glassfish
  1. glassfish
  2. GLASSFISH-19759

Support binding to OSGi services at deploy-time

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: future release
    • Component/s: cdi, OSGi-JavaEE
    • Labels:
      None

      Description

      Today the osgi-cdi portable extension supports the injection of OSGi Services into injection points marked with a custom OSGi Qualifier @OSGiService. Unfortunately this binds application components that reference these Services at deployment time to OSGi. There could be scenarios where the determination that a Service being injected is an OSGi Service, can be made at deployment-time based on the environment that the application component is part of. It would be good if we have the ability for a client of an OSGi Service to indicate that the Service is an OSGi Service at deploy-time.

        Activity

        Hide
        Sivakumar Thyagarajan added a comment -

        One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.

        Show
        Sivakumar Thyagarajan added a comment - One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.
        Hide
        TangYong added a comment -

        Siva,

        The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml.

        Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime.

        Tang

        Show
        TangYong added a comment - Siva, The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml. Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime. Tang
        Hide
        TangYong added a comment -

        Seeing siva's said carefully, Siva's means should be following,

        [Current OSGi/CDI portable extension]
        Class A

        { @OSGiService B b ... }

        The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service.

        Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage?

        Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.

        Show
        TangYong added a comment - Seeing siva's said carefully, Siva's means should be following, [Current OSGi/CDI portable extension] Class A { @OSGiService B b ... } The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service. Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage? Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.
        Hide
        Sivakumar Thyagarajan added a comment -

        Yes, Tang.

        The idea is to support the following:

        • Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO
          Class A { @Inject StockQuoteService b; }
        • At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service.
          glassfish-osgi-cdi.xml:
          <osgi-service dynamic="true">
          <managed-bean name="A">
          <attribute name ="b"/>
          </managed-bean>
          </osgi-service>
        • The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService.

        Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.

        Show
        Sivakumar Thyagarajan added a comment - Yes, Tang. The idea is to support the following: Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO Class A { @Inject StockQuoteService b; } At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service. glassfish-osgi-cdi.xml: <osgi-service dynamic="true"> <managed-bean name="A"> <attribute name ="b"/> </managed-bean> </osgi-service> The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService. Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            Sivakumar Thyagarajan
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: