glassfish
  1. glassfish
  2. GLASSFISH-18896

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

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: OSGi-JavaEE
    • Labels:
      None

      Description

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

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        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.

        Show
        Sanjeeb Sahoo added a comment - 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.
        Hide
        TangYong added a comment -

        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

        Show
        TangYong added a comment - 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
        Hide
        TangYong added a comment -

        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

        Show
        TangYong added a comment - 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
        Hide
        TangYong added a comment -

        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

        Show
        TangYong added a comment - 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
        Hide
        TangYong added a comment -

        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.

        Show
        TangYong added a comment - 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.
        Hide
        TangYong added a comment -

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

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

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: