[GLASSFISH-19395] Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement Created: 30/Nov/12 Updated: 30/Apr/13
|Affects Version/s:||future release|
|Σ Remaining Estimate:||Not Specified||Remaining Estimate:||Not Specified|
|Σ Time Spent:||Not Specified||Time Spent:||Not Specified|
|Σ Original Estimate:||Not Specified||Original Estimate:||Not Specified|
While using on-demand provisioning of OSGi modules(glassfish.osgi.ondemand=true), we must discovery and install needed bundle and the bundle's dependencies rightly. In order to reach the goal, only using OBR to generate index file is not enough because HK2 world also defined some annotations which are used for service-level dependencies, called @Service and @Inject.
Because @Service and @Inject have an another very important task for implementing on-demand bundle's starting, for example, while deploying a WAB with CDI, WebContainer will be started and at the same time, because WebContainer has a @inject JCDIService, deploying phrase will also start Weld-Integration bundle in which a @Service which implements JCDIService will be registered into HK2 registry.
So, from the point to say, @Service and @Inject also correspond to OBR capability and requirement, if we can not map the annotations, while using OBR to provision, there is an possibility that we will miss some required bundles in felix cache and caused a failure of on-demand starting.
|Comment by TangYong [ 04/Dec/12 ]|
During several day's investigation, I have some results and solution as following:
Solution: using deprecated Import-Service and Export-Service 
Although Import-Service and Export-Service head have been deprecated, we
I have confirmed that bnd or maven-bundle-plugin supports the two heads and felix obr aslo supports the two heads.
Then, we need to resolve a problem: how to generate Import-Service and Export-Service head?
Method1: manually adding Import-Service and Export-Service head into osgi.bundle file
Method2: extending some maven plugin(maybe hk2 maven plugin, maybe bnd...) to automaticlly scan bundle(@inject and @Service) and generate
Method3: Not modifying current module's manifest.mf, after generating obr-modules.xml, adding Import-Service and Export-Service head into the repository file by scanning each bundle
(2) needing to how to scan (@inject and @Service) better and maybe needing to extend osgi-adapter module
As a demostrating, I have used Method1 to add the two heads for web-glue and weld-integration and currently, the two modules have not some direct
<resource id='org.glassfish.main.web.glue/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.glue' ...'>
<resource id='org.glassfish.main.web.weld-integration/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.weld-integration' ...>
|Comment by TangYong [ 25/Jan/13 ]|
Using 's way to edit osgi.bundles , then generating an obr file.
|Comment by Sanjeeb Sahoo [ 25/Jan/13 ]|
Let's see if we can use method #3 to generate OBR capability/requirement metadata for HK2 service dependencies. I have checked in a framework for a standalone utility for generation of OBR metadata in . Let's see if we can enhance it. Thanks.
|Comment by TangYong [ 26/Jan/13 ]|
I have seen and ran glassfish-obr-builder and it is an interesting module, firstly , I want to make you confirm my understanding for the framework.
2 The framework should want to generate capability and requirement into a new obr xml file, although we can output repository info from a existed obr xml(for example, after setting glassfish.osgi.ondemand=true, however, because ondemand starting glassfish is still in incubated status, this should have no sense). But the logic of generating capability and requirement into a new obr xml file is not still finished.
Secondly, I have a question about the framework as following:
[Question about the framework]
Thirdly, backing to GLASSFISH-19395, my thinking about whether can re-use the framework or not?
|Comment by Sanjeeb Sahoo [ 26/Jan/13 ]|
It makes to reuse Felix OBR module instead of writing our own. I leave it to you to do whatever you find easier.
|Comment by TangYong [ 28/Jan/13 ]|
I have finished the issue and put sources into the following url:
You can use and see the result according to https://github.com/tangyong/glassfish-obr-builder/blob/master/README.md .
I reused osgi-adapter's ObrHandler and packaged glassfish-obr-builder as an osgi bundle and put the bundle into autostart directory, once glassfish domain starting, glassfish-obr-builder will generate an obr-modules.xml in domains/domain1/osgi-cache/felix directory. This effect is very similar to set glassfish.osgi.ondemand=true. However,glassfish-obr-builder is more simple and can make us do more research on provisioning stories.
|Comment by TangYong [ 29/Jan/13 ]|
Currently, the glassfish-obr-builder is being enhanced in the following fileds:
1 Provisioning Strategy
2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
3 Offering a way to populate obr resources from external maven repo
|Comment by TangYong [ 29/Jan/13 ]|
About the above 3, I have estimated Apache Karaf Cave, and it has such a capability to populate obr resources from an external maven repo and populate obr resources from an user local maven repo to enhance provisioning strategy.
In addition, about 1, once finishing it, I have an initial idea for making a gf kernel's evolution:
1 Defining a subsystems for glassfish according to the following rule
2)javaee 7 spec related large subsystem
3)osgi-javaee related subsystem
2 Generating System OBR using glassfish-obr-builder ahead of time
3 Integrating other the third part's frameworks
The above idea has the following advantages:
|Comment by TangYong [ 30/Jan/13 ]|
>1 Provisioning Strategy
>2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
Currently, a subsystem provioning sample can work normally.
>3 Offering a way to populate obr resources from external maven repo
4 start subsystem based on module start level defined in subsystem xml file
Basic done and a topic needs to be discussed with sahoo.
5 undeploying subsystem
|Comment by Sanjeeb Sahoo [ 05/Feb/13 ]|
This is great progress. I have been able to build it and test as well. I think there is a slight misunderstanding about how I expected the processing to happen. I noticed you are expecting us to populate Export-Service and Import-Service metadata in osgi.bundle file. I thought approach #3 meant no changes to bundles. We would introspect bundles and generate Export-Service and Import-Service metadata from @Inject and @Service annotations.
|Comment by TangYong [ 06/Feb/13 ]|
>I thought approach #3 meant no changes to bundles. We would introspect bundles and generate Export-Service and >Import-Service metadata from @Inject and @Service annotations.
I see and I will consider it.
|Comment by Sanjeeb Sahoo [ 08/Feb/13 ]|
Assigning to Tang
|Comment by TangYong [ 29/Apr/13 ]|
A new project source has sent into Sahoo and wait for his comment.
|Comment by TangYong [ 30/Apr/13 ]|
Have checked in sources.
|Comment by TangYong [ 30/Apr/13 ]|
At revision: 61748(a litter issue's fix)