[Enhancement][OSGi/CDI/JSF]CDI Beans can be available between multi-bundles about design HOT 2 OPEN

Comment author: Tang Yong <[email protected]>

This is from a real and useful scene.

[Background]
An user/company is trying to build some dynamic Java EE Application using JSF 2 + CDI + OSGi, and he wants to reach the following effect or aim,

Building a host web application bundle(called "wab1") which maybe does not contain any concrete content or web module(containing some dynamic web resources).

Eg. imagining that we are building a dynamic portal site which divides the main page into different blocks(or web modules) and each block contains some concrete dynamic web resource. Then, we deploy the portal, and in the future, we or others can develop or add these blocks into the main page. However, we can not stop the jvm or application server's instance related the portal. Then, we can access these blocks's resource using uniform portal web context path. For example, if the host wab's web context path is "/wab1", the main page's url is "http://localhost:8080/wab1/faces/home.xhtml", then, while deploying another block(web application bundle) called "module1" which contains a "about.xhtml", we wish that an user can access the "about.xhtml" from wab1's context path, that is to say, accessing "http://localhost:8080/wab1/module1/faces/about.xhtml" , the most important thing is that CDI beans in module1 can be available in wab1 context not only in module1.

Such a scene is very valuable in a mission-critical application(eg. stock trading, finance...), while in the future needing to add a new function/resource(module) , we can not stop the application or related appserver's instance.

[Example Deploying Scene]
seeing https://github.com/tangyong/GlassFishOSGiJavaEESample/tree/master/glassfish.wab.sample_dynamicCDI

Note: I only put a sample to explain the scene and an implementation prototype related GlassFish is still in my private space.

Assuming the prototype related GlassFish has been available, I will try to deploy the scene by the following steps,

1. asadmin deploy --type=osgi glassfish.wab.sample.core.jar
2. asadmin deploy --type=osgi glassfish.wab.sample.web.war
3. accessing "http://localhost:8080/wabsample/"

No any module available

4. asadmin deploy --type=osgi glassfish.wab.sample.module2.war
5. accessing "http://localhost:8080/wabsample/" again

Module2 should be displayed, and clicks "MODULE_2" link, and inputs any
text in inputbox, then, greeting page will be displayed correctly.

6. asadmin deploy --type=osgi glassfish.wab.sample.module3.war
7. accessing "http://localhost:8080/wabsample/" again

Module3 should be displayed too, and clicks "MODULE_3" link, and inputs
any text in inputbox, then, greeting page will be displayed correctly too.

[Example Explained in detailed]
I need to explain the example on some important aspects as following,

1. Host WAB(glassfish.wab.sample.web)
   seeing https://github.com/tangyong/GlassFishOSGiJavaEESample/blob/master/glassfish.wab.sample_dynamicCDI/glassfish.wab.sample.web/src/main/webapp/home.xhtml

   <ui:repeat value="#{applicationBean.modules}" var="module">
    <h:panelGrid columns="1">
      <h:link outcome="#{module.moduleName}#{module.aboutPage}" value="#{module.moduleName}" />
    </h:panelGrid>
   </ui:repeat>
   </h:panelGroup>
   <h:panelGroup layout="block" rendered="#{empty applicationBean.modules}">
        No modules available.
    </h:panelGroup>
   

By JSF external context factory, we can locate other blocks(web bundles)'s resource (here is aboutPage(about.xhtml)).

2. module2(glassfish.wab.sample.module2)
   seeing https://github.com/tangyong/GlassFishOSGiJavaEESample/blob/master/glassfish.wab.sample_dynamicCDI/glassfish.wab.sample.module2/src/main/webapp/about.xhtml

        <h:panelGrid columns="2">
            <h:outputText value="Custom Message:" />
            <h:inputText value="#{aboutBean.message}" />
        </h:panelGrid>
        <h:commandButton value="OK" action="#{aboutBean.greeting}" />
   

Here, module2 has itself backing bean called aboutBean and uses EL to access the bean.

Well, we just wish aboutBean can be available in Host WAB's context in order to the user can access about page rightly.

[Difference between the feature and RFC 193]

1. the same point
   They are all related to OSGi/CDI and all aimed to easy/simplify OSGi EE develop from JavaEE view.

2. the difference point
   RFC 193 focuses on OSGi Service's injection and CDI Bean's publishing by means of using CDI Extension, however, RFC 193 does not state how to integrate CDI/JSF(using EL) between host bundle and sub-modules and make sub-modules's beans/jsf pages available in host bundle context.

Once the feature can be implemented, we only use OSGi modularization instead of using OSGi Service, instead, the feature can be complementary to RFC 193 from another degree.

Wish I have stated the feature clearly.

from design.

Comment author: Tang Yong <[email protected]>

I have uploaded all related bundles into the following,

https://github.com/tangyong/GlassFishOSGiJavaEESample/tree/master/incubation

Pl. reading https://github.com/tangyong/GlassFishOSGiJavaEESample/blob/master/incubation/deploying_running in order to run the sample1 correctly.

BTW: in order to see how to resolve the issue , I also uploaded some patches for GlassFish OSGi-JavaEE.

Thanks
Tang

from design.