You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Jeff Faath <jf...@apache.org> on 2008/12/03 17:47:04 UTC
RE: jUDDI web services - two birds with one stone
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:jfaath@apache.org]
Sent: Tuesday, December 02, 2008 10:43 AM
To: juddi-dev@ws.apache.org
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:kurt.stam@gmail.com]
Sent: Monday, December 01, 2008 1:44 PM
To: juddi-dev@ws.apache.org
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:tcunning@redhat.com]
Sent: Saturday, November 29, 2008 4:23 PM
To: juddi-dev@ws.apache.org
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: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
Re: jUDDI web services - two birds with one stone
Posted by Kurt T Stam <ku...@gmail.com>.
sounds good to me.
Tom Cunningham wrote:
> +1 on CXF, but I don't want to throw away the axis2 work we've done,
> I'm making a profile right now to switch between the two.
>
> Kurt T Stam wrote:
>> Great work Jeff. I'm very excited about being more lightweight.
>>
>> +1 on CXF
>>
>> --Kurt
>>
>> Jeff Faath wrote:
>>>
>>> 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:jfaath@apache.org]
>>> *Sent:* Tuesday, December 02, 2008 10:43 AM
>>> *To:* juddi-dev@ws.apache.org
>>> *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:kurt.stam@gmail.com]
>>> *Sent:* Monday, December 01, 2008 1:44 PM
>>> *To:* juddi-dev@ws.apache.org
>>> *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:tcunning@redhat.com] Sent: Saturday,
>>> November 29, 2008 4:23 PM
>>> To: juddi-dev@ws.apache.org <ma...@ws.apache.org>
>>> 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: juddi-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: juddi-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: juddi-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: juddi-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
Re: jUDDI web services - two birds with one stone
Posted by Tom Cunningham <tc...@redhat.com>.
+1 on CXF, but I don't want to throw away the axis2 work we've done, I'm
making a profile right now to switch between the two.
Kurt T Stam wrote:
> Great work Jeff. I'm very excited about being more lightweight.
>
> +1 on CXF
>
> --Kurt
>
> Jeff Faath wrote:
>>
>> 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:jfaath@apache.org]
>> *Sent:* Tuesday, December 02, 2008 10:43 AM
>> *To:* juddi-dev@ws.apache.org
>> *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:kurt.stam@gmail.com]
>> *Sent:* Monday, December 01, 2008 1:44 PM
>> *To:* juddi-dev@ws.apache.org
>> *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:tcunning@redhat.com]
>> Sent: Saturday, November 29, 2008 4:23 PM
>> To: juddi-dev@ws.apache.org <ma...@ws.apache.org>
>> 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: juddi-dev-unsubscribe@ws.apache.org <ma...@ws.apache.org>
>> For additional commands, e-mail: juddi-dev-help@ws.apache.org <ma...@ws.apache.org>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org <ma...@ws.apache.org>
>> For additional commands, e-mail: juddi-dev-help@ws.apache.org <ma...@ws.apache.org>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
Re: jUDDI web services - two birds with one stone
Posted by Kurt T Stam <ku...@gmail.com>.
Great work Jeff. I'm very excited about being more lightweight.
+1 on CXF
--Kurt
Jeff Faath wrote:
>
> 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:jfaath@apache.org]
> *Sent:* Tuesday, December 02, 2008 10:43 AM
> *To:* juddi-dev@ws.apache.org
> *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:kurt.stam@gmail.com]
> *Sent:* Monday, December 01, 2008 1:44 PM
> *To:* juddi-dev@ws.apache.org
> *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:tcunning@redhat.com]
> Sent: Saturday, November 29, 2008 4:23 PM
> To: juddi-dev@ws.apache.org <ma...@ws.apache.org>
> 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: juddi-dev-unsubscribe@ws.apache.org <ma...@ws.apache.org>
> For additional commands, e-mail: juddi-dev-help@ws.apache.org <ma...@ws.apache.org>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org <ma...@ws.apache.org>
> For additional commands, e-mail: juddi-dev-help@ws.apache.org <ma...@ws.apache.org>
>
>
>
>
>
>