|<< Back to previous view|
[GLASSFISH-18973] Integrate the OSGi Remote Services implementation(eg. Apache CXF Distributed OSGi) Created: 03/Aug/12 Updated: 29/Nov/12
|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|
|Participants:||ancoron, Sanjeeb Sahoo and TangYong|
Integrating this in the JBoss OSGi distribution would provide it with support for this important OSGi spec.
|Comment by TangYong [ 03/Aug/12 02:40 PM ]|
Once implementing the feature, It will offer a hybrid JavaEE App more options.
|Comment by TangYong [ 23/Aug/12 09:46 AM ]|
Now, the integration work will start and use Multi Bundle Distribution of CXF Distributed OSGi.
DCXF Version: 1.3.1
|Comment by TangYong [ 23/Aug/12 10:07 AM ]|
Step 1(Glassfish Felix Runtime Integration)
Step1.1 Analysing DCXF Dependent Bundles
|Comment by TangYong [ 25/Aug/12 08:39 AM ]|
> Step1.1 Analysing DCXF Dependent Bundles
About initial analysing result, please see ,
To summary, I will place the following depenedent bundles and dcxf bundles into glassfish autostart/,
|Comment by TangYong [ 25/Aug/12 08:51 AM ]|
Step1.2: based Step1.1 result, place the dcxf and dependent bundles into osgi.properties and apply these bundle's start levels
On original dcxf's conf\felix.config.properties.append file, start level descriptions are as following,
I need to map these configurations into gf's osgi.properties and can start these bundles in correct order.
|Comment by TangYong [ 27/Aug/12 01:18 PM ]|
Now, based Step1.1, while I put the selected bundles into GF, DCXF has not ran normally, so I decided to put the original most of bundles on conf\felix.config.properties.append file into GF, integration way is as following:
1 make a new sub-directory called "apachedcxf" under glassfish\modules directory.
2 copy the following bundles into the apachedcxf directory,
3 modify the config/osgi.properties file liking the following,
4) define list of Apache DCXF Bundles whose start levels are copied from felix.config.properties.append
5) modify glassfish.osgi.start.level.final propety
6) add org.osgi.framework.system.packages.extra 
4 start GF domain and telnet felix shell
5 execute the following,
g! start http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-greeter-interface/1.2/cxf-dosgi-ri-samples-greeter-interface-1.2.jar
6 access "http://localhost:9090/greeter?wsdl" and see the remote service's wsdl description successfully.
Althogh the above integration seemed to be successful, there are several following problems needed to be resolved:
(1) still need to confirm the minimal bundles in order to integrate DCXF(Step 1.1's analyse is not enough)
|Comment by TangYong [ 27/Aug/12 03:30 PM ]|
Now, Glassfish with Apache DCXF 1.2 has integrated successfully!
Using Way is as following,
1 make a sub-directory called "apachedcxf" under glassfish\modules.
2 copy apache dcxf-related bundles into "apachedcxf" directory.
3 copy and override glassfish\config\osgi.properties using modified osgi.properties
4 start GF domain and telnet GF Felix Shell
5 According to Distributed OSGi Greeter Demo Walkthrough, install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-impl-1.2.jar
6 access "http://localhost:9090/greeter?wsdl" and you can see the wsdl description of exported remote service
7 start another osgi framework with Apache DCXF 1.2(or GF with Apache DCXF 1.2), install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-client-1.2.jar, then input "foobar" on popuped dialog, and you will see the following info,
|Comment by ancoron [ 27/Aug/12 06:55 PM ]|
While I think remote OSGi is something that is really useful there are some other things to look at, as I already have some deeper experience with Apache D-CXF in GlassFish 3.1:
|Comment by TangYong [ 28/Aug/12 07:37 AM ]|
Thanks for your deeper experience very much.
>Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613)
>Don't we need a different (much simpler) TopologyManager for GlassFish Clusters?
>Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port?
>Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF (http://wiki.eclipse.org
About the point("quite heavy-weight"), I think that Eclipse ECF and FuseSource Fabric maybe will bring more coupling with other framework, and of course, if having more time, I will try to invesitigate and try them.
|Comment by TangYong [ 12/Oct/12 06:48 AM ]|
Consider deferring implementing this feature for now for the following reasons:
1) need to consider start level because of dcxf self
2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).
3) need to consider integration with other osgi platform related dosgi framework, not only is dcxf, because glassfish also supports other osgi runtime as equinox.
4) integration way is still in progress and maybe needs to be combined with ondemand obr deployment.
|Comment by TangYong [ 29/Nov/12 11:39 AM ]|
Now, DOSGI-114  has been fixed and next week, DOSGi 1.4 will be released. This release is a big release and I will integrate DOSGi based the release.
>2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).
In the future, there is a plan to use OSGi/CDI to import OSGi Service from distribute OSGi runtime, So integrating dosgi has turned very important.