[GLASSFISH-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: future-release, osgi-cdi, osgi-javaee


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.

Comment by Sivakumar Thyagarajan [ 01/Mar/13 ]

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.

Comment by TangYong [ 01/Mar/13 ]


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.


Comment by TangYong [ 25/Mar/13 ]

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.

Comment by Sivakumar Thyagarajan [ 25/Mar/13 ]

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.
    <osgi-service dynamic="true">
    <managed-bean name="A">
    <attribute name ="b"/>
  • 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.

Generated at Sat Aug 27 04:22:12 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.