Steve: Developing on the Edge

Thoughts on development, Web-services, technology and mountains.

23Mar
Thu2006

Alpine restart

Despite my critique of SOAP, I tried to avoid doing my own stack. Why? It's a distraction; its just a toolkit that I need to use to get things done. Instead I went with Axis2

I got my WSRF based endpoints up and running on it back in september, before switching to CDL language stuff, using Axis2-0.93

Now, Axis-2 is at 0,95, and my code doesnt work. It took about a week to build again, because the client API was being reworked, and because maven plays up differently on work boxes (behind the firewall) versus my home system.

After building, it didnt work. I got the message failed to create WSDL for ServiceEpr reason: null and then shortly thereafter lots of things like NullPointerExceptions.

I tracked this down to some of the startup code catching any exceptions received while instantiating a class, and just printing out the exception.getMessage() (here, null), and then continuing, ignoring the fact that instantiation failed.

So, fix that. Exceptions now get thrown and passed all the way up, when they get printed in the log the full exception is printed, with stack trace.

At which point it's clear that the underlying problem is a ClassNotFoundException; my class is not being picked up. Why not? Because Axis2 now has hot-deployment of .aar archives, which are meant to contain the data+code of an endpoint. So they have a fancy classloader tree to load .aar files in their own classloader, and my classes are not being found because they are not in that .aar file, which contains nothing but a declaration of the endpoint. I don't want my files to be isolated, I want them tightly integrated with the SmartFrog that they are deploying under. If I want hot redeployment, I tell the SmartFrog runtime to undeploy that bit of the graph and redeploy it with a new configuration.

I have decided that trying to debug classloader problems in the SOAP stack by fixing places where exceptions get swallowed is an exercise in futility. I am back implementing Alpine. This has no dynamic redeploy, no ease of use features, no Java1.4 support, no annotations. It's going to be so simple I will have it working before I fly off to the Alps for my ski trip

Posted by steve at 12:12

Comments

new comment thread


	Give WS-XSUL a chance?reply to this thread On 24 March 2006 at 04: 36 Aleksander Slominski commented: Hi, did you try our toolkit - if you did and have any comments let me know - our goals were similar to Alpine though it is mean to be more of a library (Web / XML Services Utility Library) - kind WS-remix :) best, alek
	So long and thanks for all the fish!reply to this thread On 26 March 2006 at 19: 28 Davanum Srinivas commented: Seriously, You can disable hot deployment AND you can drop all your classes in WEB-INF/classes or WEB-INF/lib and use the WEB-INF/services to store ONLY the xml files for each service (w/o even an aar). If only u had asked on the dev@ list or on jira...
	Senior Principal Engineerreply to this thread On 28 August 2006 at 21: 45 Brian Horblit commented: Steve, In this blog your talked about using Axis1.x, Axis2, and of course Alpine. A friend and I who are evaluating SOAP frameworks/stacks have been wondering about the change in the teams between the Axis1.x and Axis2 projects. I wasn't sure where a good spot to post this question would be. But I've landed here after some Googling and you are listed as being a member of both teams. The transition from A1.x to A2 seems less "evolutionary" than on most Apache projects. Is there any particular reason for this that you are aware of? We are hoping to find a framework that is strongly supported by the community. Thanks very much - and sorry if this is a diversion. Brian
	Axis1.x vs Axis2reply to this thread On 28 August 2006 at 21: 47 Brian Horblit commented: Sorry for the odd title on my last post - obviously typing in my particulars and took "Title" the wrong way ;-)