On Sat, Feb 18, 2012 at 12:04 AM, Sameera Jayasoma <[email protected]> wrote:
> Hi Sagara, > > Please see my comments below. > > On Fri, Feb 17, 2012 at 1:00 PM, Sagara Gunathunga <[email protected]>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. > 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"; Class cls = 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 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 >> [email protected] >> 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: [email protected] > blog: http://tech.jayasoma.org > > Lean . Enterprise . Middleware > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Sagara Gunathunga Technical Lead; WSO2, Inc.; http://wso2.com Blog - http://ssagara.blogspot.com
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
