Well, I was able to successfully create an Apache CXF deployment project to get the web services up and running (see juddi-cxf). You can test it out by deploying the war and hitting the url:
http:// <http://%3cdomain%3e/juddi/services> <domain>/juddi/services CXF is nice and lightweight and other than a minor namespace issue, it went pretty smoothly. We should seriously consider using it as our default deployment. On another note, while researching CXF, I found out a way prevent JAX-WS from splitting out the WSDL into two files. This is what was causing the problem with the Axis2 deployment. So, now it looks like the Axis2 deployment works ( I tested it out briefly). It still needs some smoothing around the edges, but with a little work, we can get that up to speed as well. Let's make a decision on the default deployment though. I am (+1) for CXF. -Jeff From: Jeff Faath [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 02, 2008 10:43 AM To: [email protected] Subject: RE: jUDDI web services Kurt, good call. Using the older version (1.3) worked. Of course, then another issue popped up. This issue is specific to JAX-WS. The 'setPublisherAssertions' and 'getPublisherAssertions' methods of the API both return a list of publisherAssertions. When JAX-WS generates the SEI, it creates a ResponseWrapper annotation for both of these with the same localName and same className. That causes this error: com.sun.tools.internal.ws.processor.modeler.ModelerException: [failed to localize] Response wrapper bean names must be unique and must not clash with other generated classes. There are three solutions I see to this problem: 1) Modify the UDDI mega-WSDL that we retrieved from the UDDI site which is used to generate all the classes. Classes will be need to be re-generated. 2) Don't modify the UDDI WSDL, but instead make changes after the classes are generated. 3) JAX-WS allows for customizations via binding files. These might be used to fix the issue. Of these three, I'm leaning towards 1) . It's the easiest and cleanest approach. Approach 2) defeats the purpose of generating classes and 3) has a steep learning curve. Oh yea, we're not out of the woods yet. There is another issue with Axis2. See AXIS2-4160 (https://issues.apache.org/jira/browse/AXIS2-4160). That might be easily fixable or it might not. If it does turn out to be a bug that requires us to wait for the next release, well, we might want to consider switching to Apache CXF as the default WS-Stack. Comments? From: Kurt T Stam [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 1:44 PM To: [email protected] Subject: Re: jUDDI web services Can we use an older version of this jar? Before they broke it? Jeff Faath wrote: The jar file is not the problem. WSCOMMONS-377 is. We'll be hit by that bug no matter how the classes are deployed. -----Original Message----- From: Tom Cunningham [mailto:[EMAIL PROTECTED] Sent: Saturday, November 29, 2008 4:23 PM To: [email protected] Subject: Re: jUDDI web services If we uncompress the juddi-core service classes into WEB-INF/classes, will that work? Jeff Faath wrote: All, I was able to get further along in the investigation of getting the JAX-WS web services to work with Tomcat and Axis2. Turns out it wasn't working before because Axis2 couldn't properly deploy the services when classes were compiled into a jar. I think there is a way to configure Axis2 to deploy within a jar, but unfortunately there is a bigger issue. When trying to bring up the WSDL, I get a namespace conflict issue. Upon further investigation, it turns out we are getting hit by a flavor of WSCOMMONS-377. And this issue doesn't look like it's going to get fixed anytime soon. So, I'm not sure where to go from here. Any suggestions? -JF --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
