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://<domain>/juddi/services <http://%3cdomain%3e/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] <mailto:[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] <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
