Out of curiosity, if you run wsgen -wsdl from Java6 on the implementation 
class, what does it spit out?

Basically, the three "names" on WebService:

name - really just for the SEI, is the portType name
serviceName - name for the Service.  Just for the impl
portName - name of the port.  Just for the impl

Now, the trick comes when things are ommitted.  If serviceName is ommitted, 
its the simple name of the class + "Service".    If portName is ommitted, then 
the "name" attribute is used with "Port" suffixed.  If name is also ommitted, 
it is the simple name of the class+ "Port".

HOWEVER, in your case, your beans.xml (in juddi-cxf/src/main/webapp/WEB-
INF/beans.xml) is overriding the values specified in the @WebService 
annotation.   That's where the UDDI_Security_Port value is coming from.  If 
you don't need the serviceName and endpointName set there, I would remove 
those and let the annotations do thier thing.

Dan






On Wednesday 17 November 2010 2:33:25 pm Kurt T Stam wrote:
> I just checked the wsdl generated by the same jUDDI code. When deployed
> to tomcat + CXF it says:
> 
> <wsdl:service name="UDDI_Security_Port">
> <wsdl:port binding="tns:UDDI_Security_PortSoapBinding"
> name="UDDISecurityServicePort">
> <soap:address location="http://localhost:8080/juddiv3/services/security"/>
> </wsdl:port>
> </wsdl:service>
> 
> The same code deployed to JBoss + CXF
> 
> <wsdl:service name="UDDISecurityService">
> <wsdl:port binding="tns:UDDISecurityServiceSoapBinding"
> name="UDDISecurityImplPort">
> <soap:address location="http://127.0.0.1:8080/juddiv3/services/security"/>
> </wsdl:port>
> </wsdl:service>
> 
> So clearly the annotations are used in different ways by the two WS
> stacks (even if the CXF implementation is used in both cases). I will
> take this discussion to the CXF forum.
> 
> Thx,
> 
> --Kurt
> 
> On 11/16/10 10:01 PM, Kurt T Stam wrote:
> > I need some help understanding the WebService Annotations.
> > 
> > 1. In the jUDDI project we generated our WebServices Java classes from
> > the WSDL using the CXF tooling. For the InquiryService it created
> > annotations on the interface of:
> > 
> > @WebService(name = "UDDI_Inquiry_PortType", targetNamespace =
> > "urn:uddi-org:v3_service")
> > public interface UDDIInquiryPortType
> > 
> > and on the implementation class:
> > 
> > @WebService(serviceName="UDDIInquiryService",
> > 
> >             endpointInterface="org.uddi.v3_service.UDDIInquiryPortType",
> >             targetNamespace = "urn:uddi-org:v3_service")
> > 
> > public class UDDIInquiryImpl extends AuthenticatedService implements
> > UDDIInquiryPortType
> > 
> > 
> > 
> > 2. On the client side we are calling into the service with:
> > 
> > QName qName = new QName("urn:uddi-org:v3_service", "UDDI_Inquiry_Port");
> > Service service = Service.create(new URL(endpointURL), qName);
> > inquiryService = (UDDIInquiryPortType)
> > service.getPort(UDDIInquiryPortType.class);
> > 
> > 
> > 3. All seems to work quite well, however
> > https://issues.apache.org/jira/browse/JUDDI-428 reports that they get
> > the following warning when deployed to JBoss
> > 
> > "2010-11-02 14:00:36,921 WARN
> > [org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder] Cannot
> > get service '{urn:uddi-org:v3_service}UDDIInquiryService' from the
> > given wsdl definitions! Eventual policies attached to this service
> > won't be considered."
> > 
> > QUESTION:
> > 
> > Can someone explain to me what the difference is between the
> > @WebService name on the interface and the @WebService serviceName on
> > the implementation. Should they be the same as the warning seems to
> > suggest? Or might this be a bug on the JBoss side of things.
> > 
> > Thanks for any insight you may have!
> > 
> > --Kurt
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]

-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to