]
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: