WSAD JavaBean WS generation

[Doug Hoople]

OK Rancheros...

I give up. I'm using the trial version of WebSphere Application Developer 5.1, and almost all of my JavaBean to WebService attempts give me an InstantiationException in the end.

I've created all the other Redbook variants, EJB bottom-up, JavaBean top-down, EJB bottom-up with JMS, URL (servlet), DADX, so I must be doing something right. I've generated all the test clients in all their glorious forms.

But when I try the simplest of all the Web Service generation demonstrations (the first one in Chapter 15 of the Redbook), bottom-up JavaBean, I keep running into the same wall. I've tried a variety of different dumbed-down "JavaBean" classes, and I've observed all the rules (public constructor, getters/setters, Dynamic Web Project, ...), but they all give me the same grief.

I HAVE, however, reversed the cycle, generated a JavaBean skeleton from WSDL, made the quick mods for a "HelloWorld" and had it turn out fine (!!! :-((((). That would be great if it led to the revelation about the missing piece, but it didn't. Oddly enough, it worked when the exported "class" was an interface that extended java.rmi.Remote, implemented immediately by a <MyClass>SoapBindingImpl concrete class. This all worked fine, even though the server log reports not finding the "class" on starup (it nonetheless AbstractFactory-instantiates the interface-based object just fine).

Ok, I know this is getting long, and the problem doesn't describe precisely, but I've tried a lot of things to get this working and am still really puzzled. If I hadn't driven through the rest of the Redbook stuff, I'd be crying right now... as it is I'm still tearing out my hair. I've even applied WSAD updates with no change in behavior.

At the very least, please tell me I'm not the only one with this tale of Redbook woe?!!!?? I haven't read about it in the forums, so am worried about working in my own private Twilight Zone (doo doo doo doo).

What am I doing wrong??? It's got to be as obvious as that damned fly buzzing into the moose's nose!!!

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

[Doug Hoople]

Well maybe not quite so obvious. I found the problem, or at least the problem points.

The secret's in the webservices.xml file, which is specified through JSR-109. For a really good general description of all the file mappings from WSDL through webservices.xml and jaxrpcmapping.xml file and finally back to the web.xml file, take a look at:

http://www-128.ibm.com/developerworks/library/ws-jsrart/

In this article, they literally point at the mappings required to make it all work. In my case the two key elements were in the <port-component> section of the webservices.xml file:

<service-endpoint-interface>itso.bean.WeatherForecast</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1071529026058">
<servlet-link>itso_bean_WeatherForecast</servlet-link>
</service-impl-bean>

and the <servlet-link> element refers to a section of the web.xml file, which in this case looks like:

<servlet>
<servlet-name>itso_bean_WeatherForecast</servlet-name>
<servlet-class>itso.bean.WeatherForecast</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Refocusing, note that the <service-endpoint-interface> points to a class (itso.bean.WeatherForecast), and that this will resolve to the <servlet-class> class itso.bean.WeatherForecast (whoa, dude, that doesn't sound right!). Two problems here: 1) These two references point to the same class, and, more importantly, 2) what's supposed to be pointing to an interface is actually pointing to a class.

Apparently the <service-endpoint-interface> needs to point to an interface, so building a Web Service from a class instead of an interface (as instructed on p. 253 of the Redbook "Select the WeatherForecast class...") is 1) wrong and 2) the only way the wizard will let you do it.

In my book, that's a bug. Easily solved, though... Build the Web Service as described, then change the class to an interface of the same name, and paste the implementation into a new class in the same package. Fix the web.xml <servlet-class> so that it loads your new implementation class instead of the interface and VOILA! your problem is solved.

Simple, no? NO.

At least now I'm in better control of JSR-109.

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4
[ January 19, 2005: Message edited by: Doug Hoople ]