Re: [Carbon-dev] Ground work for Admin Service port to JAX-WS
On Sat, Feb 18, 2012 at 12:04 AM, Sameera Jayasoma same...@wso2.com wrote:
Hi Sagara,
Please see my comments below.
On Fri, Feb 17, 2012 at 1:00 PM, Sagara Gunathunga sag...@wso2.comwrote:
I started to work on ${Subject} following are the sub tasks involve with
this.
1.) Write a new Carbon based JAXWSDeployer to deploy a bundles as a Axis2
JAX-WS service.
Current Carbon Axis2ServiceRegistry look for service.xml file in a bundle
and deploy bundle as a native Axis2 service. Since Axis2 JAX-WS deployment
does not use any meta data file it is required to set new entry on MANIFEST
file to identify JAX-WS services. At the moment I have completed most part
of this JAXWSDeployer, it is possible to deploy and invoke JAX-WS service
but still have to solve few classloading issues.
There are few ClassNotFoundExceptions occurred for non-existing classes
when I use BundleClassLoader to deploy services. But still WSDL generated
and possible to invoke service successfully too . This is not the case if I
use SystemClassLoader through axisConfig.getSystemClassLoader() instead
of BundleClassLoader. I will debug Axis2 JAX-WS deployment within Carbon
further and see what cause this issue.
As per the discussion we had on this effort, we need to reuse the JAXWS
service deployment code here. AFAIK, we are trying the deploy the JAXWS
Service in the OSGi bundle by giving the file path of the bundle. This is
not the proper way of doing this IMHO. Thats why you are getting all sorts
of class loading issues.
Hi Sameera,
After above discussion with you I have changed JAXWS service deployment
code, now it's pretty much similar to existing service deployment approach.
I was able to create a small sample code to demonstrate above issue just
within Carbon codes without dealing any JAX-WS codes. This is what I found
Assume we have following method and sample.ObjectFactory class does not
exists.
private static Class forName(final boolean initialize, final ClassLoader
classloader)
throws ClassNotFoundException {
Class cl = null;
try {
cl = (Class) AccessController
.doPrivileged(new PrivilegedExceptionAction() {
public Object run() throws ClassNotFoundException {
String className = sample.ObjectFactory;
Classcls = Class.forName(className,
initialize,
classloader);
return cls;
}
});
} catch (PrivilegedActionException e) {
throw (ClassNotFoundException) e.getException();
}
return cl;
}
If I call above method within following code segment expected behavior
should be no Exception message on console. If I pass ClassLoader that
supports for AccessControlContext ( e.g - URLClassLoader,
org.apache.axis2.deployment.DeploymentClassLoader etc) I can see expected
behavior that is no error message on console. But if I use
BundleClassLoader I can see exception messages on console, according to
following code this is not the expected behavior.
try {
forName(true, loader);
} catch (ClassNotFoundException e) { }
Is there any specific reason that BundleClassLoader does not support for
AccessControlContext ? If not shall I add AccessControlContext support for
it ?
Note :- Axis2 JAX-WS code try to load number of non-existing classes and
ignore ClassNotFoundExceptions but with BundleClassLoader those exceptions
visible on console. This does not make any effect on functionality but we
can't allow this behavior, as I mislead people can mislead with those
exception messages on console.
+1 to have a meeting to discuss in further.
Thanks !
We need to do this keeping in mind that these services are coming from
OSGi bundles. One such improvement is to set the bundle classloader as the
service classloader.
I suggest having a meeting to discuss in further.
Thanks,
Sameera.
2.) Port existing Axis2 native Admin services to to use JAX-WS/ JAXB.
I went through services.xml files of all the Admin services and it's
looks like most of them can be port into JAX-WS programing model. Since
Axis2 JAX-WS does not use any meta data file we may have to use MANIFEST
file to set some of the entries available on services.xml file today.
One issue here is few Admin services invoke Axis2 modules, in order to
port these services we have to port some of the Axis2 modules into JAX-WS
modules first.
In generally this modification allow users to write Admin services using
JAX-WS programming model instead of Axis2 native service model. BTW this
modification does not address requirement of decoupling Carbon core and
Axis2. Though we move Admin services to JAX-WS programming model still we
have to use Axis2 JAX-WS deployment framework to deploy services we
Re: [Carbon-dev] Ground work for Admin Service port to JAX-WS
Before doing a lot of work in this area please first do a thing slice, and
compare the performance with existing admin services. We also need to
figure out how to add customers parameters permissions to these services
using annotations.
--
Afkham Azeez
Sent from my phone
On Feb 17, 2012 1:01 PM, Sagara Gunathunga sag...@wso2.com wrote:
I started to work on ${Subject} following are the sub tasks involve with
this.
1.) Write a new Carbon based JAXWSDeployer to deploy a bundles as a Axis2
JAX-WS service.
Current Carbon Axis2ServiceRegistry look for service.xml file in a bundle
and deploy bundle as a native Axis2 service. Since Axis2 JAX-WS deployment
does not use any meta data file it is required to set new entry on MANIFEST
file to identify JAX-WS services. At the moment I have completed most part
of this JAXWSDeployer, it is possible to deploy and invoke JAX-WS service
but still have to solve few classloading issues.
There are few ClassNotFoundExceptions occurred for non-existing classes
when I use BundleClassLoader to deploy services. But still WSDL generated
and possible to invoke service successfully too . This is not the case if I
use SystemClassLoader through axisConfig.getSystemClassLoader() instead
of BundleClassLoader. I will debug Axis2 JAX-WS deployment within Carbon
further and see what cause this issue.
2.) Port existing Axis2 native Admin services to to use JAX-WS/ JAXB.
I went through services.xml files of all the Admin services and it's looks
like most of them can be port into JAX-WS programing model. Since Axis2
JAX-WS does not use any meta data file we may have to use MANIFEST file to
set some of the entries available on services.xml file today.
One issue here is few Admin services invoke Axis2 modules, in order to
port these services we have to port some of the Axis2 modules into JAX-WS
modules first.
In generally this modification allow users to write Admin services using
JAX-WS programming model instead of Axis2 native service model. BTW this
modification does not address requirement of decoupling Carbon core and
Axis2. Though we move Admin services to JAX-WS programming model still we
have to use Axis2 JAX-WS deployment framework to deploy services we just
change web service programming model only. In future if we decide to move
to CXF then we have to repeat above step-1 again that is write a Carbon
based CXF service deployer to deploy a bundle as a service. JAX-WS spec
does not specify any generic deployment approach hence each vendor define
their own deployment mechanism. In case if we want to support Carbon for
both Axis2 and CXF then Carbon will need to couple with both Axis2 and
CXF.
Thanks !
--
Sagara Gunathunga
Technical Lead; WSO2, Inc.; http://wso2.com
Blog - http://ssagara.blogspot.com
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Ground work for Admin Service port to JAX-WS
Hi Sagara,
Please see my comments below.
On Fri, Feb 17, 2012 at 1:00 PM, Sagara Gunathunga sag...@wso2.com wrote:
I started to work on ${Subject} following are the sub tasks involve with
this.
1.) Write a new Carbon based JAXWSDeployer to deploy a bundles as a Axis2
JAX-WS service.
Current Carbon Axis2ServiceRegistry look for service.xml file in a bundle
and deploy bundle as a native Axis2 service. Since Axis2 JAX-WS deployment
does not use any meta data file it is required to set new entry on MANIFEST
file to identify JAX-WS services. At the moment I have completed most part
of this JAXWSDeployer, it is possible to deploy and invoke JAX-WS service
but still have to solve few classloading issues.
There are few ClassNotFoundExceptions occurred for non-existing classes
when I use BundleClassLoader to deploy services. But still WSDL generated
and possible to invoke service successfully too . This is not the case if I
use SystemClassLoader through axisConfig.getSystemClassLoader() instead
of BundleClassLoader. I will debug Axis2 JAX-WS deployment within Carbon
further and see what cause this issue.
As per the discussion we had on this effort, we need to reuse the JAXWS
service deployment code here. AFAIK, we are trying the deploy the JAXWS
Service in the OSGi bundle by giving the file path of the bundle. This is
not the proper way of doing this IMHO. Thats why you are getting all sorts
of class loading issues.
We need to do this keeping in mind that these services are coming from OSGi
bundles. One such improvement is to set the bundle classloader as the
service classloader.
I suggest having a meeting to discuss in further.
Thanks,
Sameera.
2.) Port existing Axis2 native Admin services to to use JAX-WS/ JAXB.
I went through services.xml files of all the Admin services and it's looks
like most of them can be port into JAX-WS programing model. Since Axis2
JAX-WS does not use any meta data file we may have to use MANIFEST file to
set some of the entries available on services.xml file today.
One issue here is few Admin services invoke Axis2 modules, in order to
port these services we have to port some of the Axis2 modules into JAX-WS
modules first.
In generally this modification allow users to write Admin services using
JAX-WS programming model instead of Axis2 native service model. BTW this
modification does not address requirement of decoupling Carbon core and
Axis2. Though we move Admin services to JAX-WS programming model still we
have to use Axis2 JAX-WS deployment framework to deploy services we just
change web service programming model only. In future if we decide to move
to CXF then we have to repeat above step-1 again that is write a Carbon
based CXF service deployer to deploy a bundle as a service. JAX-WS spec
does not specify any generic deployment approach hence each vendor define
their own deployment mechanism. In case if we want to support Carbon for
both Axis2 and CXF then Carbon will need to couple with both Axis2 and
CXF.
Thanks !
--
Sagara Gunathunga
Technical Lead; WSO2, Inc.; http://wso2.com
Blog - http://ssagara.blogspot.com
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
--
Sameera Jayasoma
Technical Lead and Product Manager, WSO2 Carbon
WSO2, Inc. (http://wso2.com)
email: same...@wso2.com
blog: http://tech.jayasoma.org
Lean . Enterprise . Middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[Carbon-dev] Ground work for Admin Service port to JAX-WS
I started to work on ${Subject} following are the sub tasks involve with
this.
1.) Write a new Carbon based JAXWSDeployer to deploy a bundles as a Axis2
JAX-WS service.
Current Carbon Axis2ServiceRegistry look for service.xml file in a bundle
and deploy bundle as a native Axis2 service. Since Axis2 JAX-WS deployment
does not use any meta data file it is required to set new entry on MANIFEST
file to identify JAX-WS services. At the moment I have completed most part
of this JAXWSDeployer, it is possible to deploy and invoke JAX-WS service
but still have to solve few classloading issues.
There are few ClassNotFoundExceptions occurred for non-existing classes
when I use BundleClassLoader to deploy services. But still WSDL generated
and possible to invoke service successfully too . This is not the case if I
use SystemClassLoader through axisConfig.getSystemClassLoader() instead
of BundleClassLoader. I will debug Axis2 JAX-WS deployment within Carbon
further and see what cause this issue.
2.) Port existing Axis2 native Admin services to to use JAX-WS/ JAXB.
I went through services.xml files of all the Admin services and it's looks
like most of them can be port into JAX-WS programing model. Since Axis2
JAX-WS does not use any meta data file we may have to use MANIFEST file to
set some of the entries available on services.xml file today.
One issue here is few Admin services invoke Axis2 modules, in order to port
these services we have to port some of the Axis2 modules into JAX-WS
modules first.
In generally this modification allow users to write Admin services using
JAX-WS programming model instead of Axis2 native service model. BTW this
modification does not address requirement of decoupling Carbon core and
Axis2. Though we move Admin services to JAX-WS programming model still we
have to use Axis2 JAX-WS deployment framework to deploy services we just
change web service programming model only. In future if we decide to move
to CXF then we have to repeat above step-1 again that is write a Carbon
based CXF service deployer to deploy a bundle as a service. JAX-WS spec
does not specify any generic deployment approach hence each vendor define
their own deployment mechanism. In case if we want to support Carbon for
both Axis2 and CXF then Carbon will need to couple with both Axis2 and
CXF.
Thanks !
--
Sagara Gunathunga
Technical Lead; WSO2, Inc.; http://wso2.com
Blog - http://ssagara.blogspot.com
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
