Issue Details (XML | Word | Printable)

Key: GLASSFISH-19395
Type: Task Task
Status: In Progress In Progress
Priority: Critical Critical
Assignee: TangYong
Reporter: TangYong
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Mapping HK2 annotations(@Service and @Inject) into OBR capability and requirement

Created: 30/Nov/12 07:54 AM   Updated: 30/Apr/13 12:46 PM
Component/s: OSGi
Affects Version/s: future release
Fix Version/s: None

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Tags:
Participants: Sanjeeb Sahoo and TangYong

  • Sub-Tasks:
  • All
  • Open

 Description  « Hide

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.



TangYong added a comment - 30/Apr/13 12:46 PM

At revision: 61748(a litter issue's fix)


TangYong added a comment - 30/Apr/13 08:41 AM

Have checked in sources.

revision: 61742


TangYong added a comment - 29/Apr/13 04:47 AM

A new project source has sent into Sahoo and wait for his comment.


Sanjeeb Sahoo added a comment - 08/Feb/13 12:58 AM

Assigning to Tang


TangYong added a comment - 06/Feb/13 03:53 AM

>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.

Thanks

Tang


Sanjeeb Sahoo added a comment - 05/Feb/13 03:48 PM

Tang,

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.

Sahoo


TangYong added a comment - 30/Jan/13 02:23 PM

>1 Provisioning Strategy
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/11

Done

>2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/13

Being enhancing...

Currently, a subsystem provioning sample can work normally.

>3 Offering a way to populate obr resources from external maven repo
>seeing: https://github.com/tangyong/glassfish-obr-builder/issues/8
>However, 3's priority is low.

Undo

4 start subsystem based on module start level defined in subsystem xml file
seeing https://github.com/tangyong/glassfish-obr-builder/issues/15

Basic done and a topic needs to be discussed with sahoo.

5 undeploying subsystem

Doing


TangYong added a comment - 29/Jan/13 02:59 PM

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
1)admin subsystem
The subsystem is defined by admin infra related bundles, and while starting glassfish domain, we must deploy the subsystem because it is a core bus of glassfish self.

2)javaee 7 spec related large subsystem
The large subsystem is constituted by many subsystems according to javaee 7 spec. For example, for EJB spec, we can define a ejb subsystem which is defined by ejb related bundles. Once we make such a partition, a user can deploy these subsystem in on-demand way according to his/her requirement.

3)osgi-javaee related subsystem
The subsystem is constituted by osgi-javaee related bundles which currently are put into autostart directory.

2 Generating System OBR using glassfish-obr-builder ahead of time
If having 1, while starting glassfish domain, we can firstly generate Glassfish System OBR using glassfish-obr-builder, and according to the Glassfish System OBR, we can deploy admin subsystem and lately also use the Glassfish System OBR to deploy other subsystems.

3 Integrating other the third part's frameworks
Integrating other the third part's frameworks can also use subsystem concept to do. We only need to offer a subsystem which is constituted by the third part's frameworks related bundles. In such a subsystem definition, an user can offer an user-defined obr repo url as provisioning repo. Then, while deploying such a subsystem, we firstly provision bundles from Glassfish System OBR because some bundles maybe have been offered by glassfish, if not finding proper resources, we will provision bundles from user-defined obr repo.

The above idea has the following advantages:
1) speeding up glassfish domain starting
2) saving more spaces rather than installing all bundles into felix cache.
3) making an user have more profiles, for example, if the user creates two domains, in domain1, he/she can deploy some javaee related bundles, in domain2, he/she can deploy some osgi-javaee related bundles.


TangYong added a comment - 29/Jan/13 02:18 PM

Currently, the glassfish-obr-builder is being enhanced in the following fileds:

1 Provisioning Strategy
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/11

2 Creating a client bundle to make an experiment to test 1 using glassfish-obr-builder
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/13

3 Offering a way to populate obr resources from external maven repo
seeing: https://github.com/tangyong/glassfish-obr-builder/issues/8
However, 3's priority is low.


TangYong added a comment - 28/Jan/13 05:44 AM

Hi sahoo,

I have finished the issue and put sources into the following url:

https://github.com/tangyong/glassfish-obr-builder

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.

Thanks


Sanjeeb Sahoo added a comment - 26/Jan/13 02:23 PM

It makes to reuse Felix OBR module instead of writing our own. I leave it to you to do whatever you find easier.

Thanks,
Sahoo


TangYong added a comment - 26/Jan/13 01:30 PM - edited

Hi Sahoo,

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.

[My understanding]
1 glassfish-obr-builder's aim should be similar to felix obr to generate capability and requirement from bundle's Manifest.MF.

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]
Why we use felix obr to generate capability and requirement and instead, re-invent a wheel?
Whether because the framework's API is more easy and convenient than felix obr's API or not?

Thirdly, backing to GLASSFISH-19395, my thinking about whether can re-use the framework or not?

[My thinking]
Sure, no problem, can re-use the framework.And we only need to add the logic of generating capability and requirement from a directory containing OSGi bundles. A point to notice is that if using felix obr, we will directly use felix obr's api to finish such things.

Thanks.


Sanjeeb Sahoo added a comment - 25/Jan/13 02:43 PM

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 [1]. Let's see if we can enhance it. Thanks.

[1] https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/experimental/glassfish-obr-builder. Se


TangYong added a comment - 25/Jan/13 02:35 PM

Using [3]'s way to edit osgi.bundles , then generating an obr file.


TangYong added a comment - 04/Dec/12 03:41 AM

During several day's investigation, I have some results and solution as following:

Solution: using deprecated Import-Service and Export-Service [1][2]

Although Import-Service and Export-Service head have been deprecated, we
can still use the head to meet our demand because we can consider hk2 level's service dependency as some static service dependency.

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

[Analyse Advantage/Disadvantage]
Advantage: simple and fast
Disadvantage: needing to large scale edit osgi.bundle

Method2: extending some maven plugin(maybe hk2 maven plugin, maybe bnd...) to automaticlly scan bundle(@inject and @Service) and generate
the two heads

[Analyse Advantage/Disadvantage]
Advantage: not editing osgi.bundle manually
Disadvantage: a litter complex and needing to master maven or bnd, and also needing to invesigate how to extend

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

[Analyse Advantage/Disadvantage]
Advantage: not editing osgi.bundle manually and not extending current build architecture
Disadvantage: (1) needing to how to add Import-Service and
Export-Service head into the repository file because felix obr Api has not published similar api. (Note: I have sent a email to felix to consult the thing)

(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
dependency(module layer dependency), however, web-glue has a hk2 service
dependency[3] on weld-integration. So, after I edited osgi.bundles of the two modules, obr-modules.xml has added the service related requirement/capability for the two modules.

<resource id='org.glassfish.main.web.glue/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.glue' ...'>
...
<require name='service' filter='(service=com.sun.enterprise.container.common.spi.JCDIService)' extend='false' multiple='true' optional='false'>Import Service com.sun.enterprise.container.common.spi.JCDIService</require>
...

<resource id='org.glassfish.main.web.weld-integration/4.0.0.SNAPSHOT' symbolicname='org.glassfish.main.web.weld-integration' ...>
...
<capability name='service'>
<p n='service' v='com.sun.enterprise.container.common.spi.JCDIService'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.api.naming.NamedNamingObjectProxy'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.weld.ResourceLoaderImpl'/>
</capability>
<capability name='service'>
<p n='service' v='com.sun.enterprise.web.WebComponentDecorator'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.api.container.Container'/>
</capability>
<capability name='service'>
<p n='service' v='org.glassfish.weld.WeldDeployer'/>

[1]: http://wiki.osgi.org/wiki/Import-Service
[2]: RFC-0112 Bundle Repository
[3]: in WebContainer.java, the following declares a service dependency
@Inject @Optional
private JCDIService jcdiService