Issue Details (XML | Word | Printable)

Key: GLASSFISH-18896
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Sanjeeb Sahoo
Reporter: Sanjeeb Sahoo
Votes: 0
Watchers: 3
Operations

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

[osgi/cdi] Allow criteria to be configurable in OSGiService

Created: 13/Jul/12 06:59 AM   Updated: 01/Nov/12 07:36 AM
Component/s: OSGi-JavaEE
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags:
Participants: Sanjeeb Sahoo and TangYong


 Description  « Hide

We should allow some kind of property substitution in filter criteria attribute of @OSGiService.



TangYong added a comment - 10/Aug/12 06:18 AM

I wish that sahoo can explain GLASSFISH-18896 in detail and what is mean of "Allow criteria to be configurable".


TangYong added a comment - 10/Aug/12 06:18 AM

Sahoo Said:

What I meant by configurable service property in GLASSFISH-18896 is
that instead of hard coding the serviceCriteria if developer can use
tokens which can get replaced by values set during deployment, that will
be more flexible.


TangYong added a comment - 31/Oct/12 01:58 AM

Now, the feature should be considered ahead of time because design for the feature seemed to have a relationship with some issues(for example, Glassfish-19215).

If implementing the feature, a user maybe use the following deploying command to specify serviceCriteria,

asadmin deploy --type=osgi --properties serviceprops=(name=lang,value=__CH) e:\test_sample1.jar

There is a important topic that we should make OSGiServiceExtension can obtain current deployed bundle's serviceprops which is from "--properties". However, OSGiServiceExtension is not related to DeploymentContext at all.

So, I consider a solution which is similar to how OSGiEJBDeployer obtains OSGiApplicationInfo, that is to say, on the first deploying phrase, we register serviceprops as a OSGi service once finding serviceprops, then, in OSGiServiceExtension, getting current bundle's serviceprops by OSGi service.

Then, the reason that I say the feature maybe have a relationship with Glassfish-19215 is that whether having some design possibility rather than registering serviceprops as a OSGi service.

Thanks.
Tang


TangYong added a comment - 31/Oct/12 03:04 AM

Apart from the above problem, there is another problem needed to be discussed:

if the user used the following command with service property:

asadmin deploy --type=osgi --properties serviceprops=(name=lang,value=__CH) e:\test_sample1.jar

For OSGi/CDI, there are two places that can use the serviceprops:

1) @Publish
using the serviceprops to register OSGi service

2) @OSGiService
using the serviceprops to get OSGi service

Then,

One problem is that once specifying the serviceprops, whether bean classes with @Publish in current bundle all register OSGi Service using * the same serviceprops * or not?

Another problem is that once bean classes with @Publish in current bundle * all or part of them * register OSGi Service using the serviceprops, whether bean classes with @OSGiService all get OSGi Service using * the same serviceprops * or not?

Thanks
Tang


TangYong added a comment - 31/Oct/12 12:33 PM

Apart from the above problems, there is a more important problem needed to be discussed too,

After a user stopped gf's domain, and then is ready to re-start gf's domain, the bundle's deploying on re-starting phrase should keep the bundles's properties or states(serviceprops) the same with previous deploying. That is to say, "serviceprops" must have effect.

In order to resolve the problem, I think that after deploying a bundle with "--properties serviceprops", the service properties should be written into domain.xml liking the following:

<application location="${com.sun.aas.instanceRootURI}/applications/stockquote_service_usingcdi/" name="stockquote_service_usingcdi" object-type="user">
...
<property name="defaultAppName" value="stockquote_service_usingcdi"></property>
<module name="stockquote_service_usingcdi">
...
<property name="archiveType" value="osgi"></property>
...
<!--★Adding Service Properties★ -->
<property name="serviceprops" value="name=lang,value=__CH"></property>

<engine sniffer="osgi"></engine>
</module>
</application>

In such way, when restarting domain, gf can deploy the plain cdi bundle and register/get OSGi Service with previous service properties.

Tang


Sanjeeb Sahoo added a comment - 01/Nov/12 07:36 AM

I don't think we should use --properties option of deployment which is available only if user is using deploy CLI. We need something that's applicable to other modes of deployment. The two choices that come to mind are:

a) Using config admin to configure service criterias
b) Using some sort of deployment plan or runtime descriptors as used by Java EE.