[jbossws-issues] [JBoss JIRA] (JBWS-3390) jax-ws-catalog.xml not being used with @WebServiceRef() annotation in JBoss AS 7.1.0.Beta1 "Tesla"
Fred Welland (Commented) (JIRA)
jira-events at lists.jboss.org
Wed Nov 23 18:29:40 EST 2011
[ https://issues.jboss.org/browse/JBWS-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645287#comment-12645287 ]
Fred Welland commented on JBWS-3390:
------------------------------------
So the problem may even be deeper than just ignoring the jax-ws-catalog.xml file.
After taking what I learned from the sample WAR attached to the issue; I applied that to my real application. Unlike the sample application whose, JSF managed bean is the class that uses @WebServiceRef() and makes the WS call...the real application does this:
JSF Managed bean delegates to a different class (call it 'dal') that is @Inject() by the managed bean. This dal class does the @WebServiceRef() and then makes the WS calls.
@WebServiceRef in this DAL doesn't seem to work at all in this case. Even when I explictly refer to a WSDL like this (as :
@WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/TemplateService.wsdl")
private com.blah.blah.template.TemplateServiceService service;
As mentioned in the issue, A annotation like: @WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/TemplateService.wsdl") 'in' the Managed Bean directly seems to work OK; but appearantly not in a deeper layers...
...grumble..
> jax-ws-catalog.xml not being used with @WebServiceRef() annotation in JBoss AS 7.1.0.Beta1 "Tesla"
> --------------------------------------------------------------------------------------------------
>
> Key: JBWS-3390
> URL: https://issues.jboss.org/browse/JBWS-3390
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.0.0.CR1
> Environment: JBoss AS 7.1.0.Beta1 "Tesla"
> Fedora 15 (2.6.40.6-0.fc15.i686)
> java version "1.6.0_27"
> Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
> Java HotSpot(TM) Server VM (build 20.2-b06, mixed mode)
> Reporter: Fred Welland
> Attachments: HelloWSWorld.jar, WebHello.war
>
>
> @WebServiceRef(wsdlLocation = "http://my.nowhereland.com/HelloWSWorld/Hello/Hello?wsdl") always try to resolve the host (my.nowhereland.com) even if there is a jax-ws-catalog.xml file that maps the location url to a path in the WAR.
> Here is thread detailing the issue: http://community.jboss.org/message/637964
> The 2 packages detail are the parts to reproduce the problem (source code in jar/war).
> HelloWSWorld.jar: Exceedingly simple SLSB jar with a WS
> WebHello.war: JSF Web App that is simple client to the above WS ejb jar.
> Deployed to 'standalone' and just used the web console to deploy the modules.
> The same 2 products can be deployed to Glassfish 3.1.1. GF resolves the @WebServiceAnnotation() annotation and seems happy with using the mappings in the jax-ws-catalog.xml. The @PostConstruct() method can then re-assign ENDPOINT_ADDRESS_PROPERTY for WS invocation. In JBOSS as 7.1.0beta1 the following (bottom part of the stack trace) is tossed while the annotation is being processed:
> javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://my.nowhereland.com/HelloWSWorld/Hello/Hello?wsdl'.: java.net.UnknownHostException: my.nowhereland.com
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:239)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:186)
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:92)
> ... 76 more
> Caused by: java.net.UnknownHostException: my.nowhereland.com
> Of course the @PostContruct never gets the opportunity to execute and change the ENDPOINT_ADDRESS_PROPERTY.
> I have found that an annotation like:
> @WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/Hello.wsdl")
> seems to make JBoss happy and the @PostContruct fires and things are OK. However, I don't know if this will work in GF.
> My objectives are:
> *to have our WAR work on both GF and JBOSS (and maybe others)
> *war code refers to our services via canonical service location
> *provide jax-ws-catalog mappings for local/in-war wsdl access
> *allow WAR code to override the canonical locations when they are in 'DEV-Mode' or detect some other run-time discriminator used to change the service location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossws-issues
mailing list