[GLASSFISH-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13 Updated: 25/Mar/13
|Fix Version/s:||future release|
|Reporter:||Sivakumar Thyagarajan||Assignee:||Sivakumar Thyagarajan|
|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]
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 ]|
The idea is to support the following:
Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.