Hi Dan,
I'll do this investigation/debug tomorrow morning (Europe time) and let
you know as soon as possible.
Thanks
Alessio
Daniel Kulp wrote:
Alessio,
This SOUNDS like there a ResourceResolver registered on the Bus's
ResourceManager that can resolve a URL, but for some reason is not able to
open a stream for it. Does JBoss integrations stuff register a
ResourceResolver? If so, can you do a quick debug with that and check if
that's the case? It might be just a little fix in the ResourceResolver.
If that isn't the case or if you cannot figure anything better out, let me
know and I'll withdraw the vote in the morning and rebuild. :-(
Dan
On Mon November 16 2009 3:54:29 pm Alessio Soldano wrote:
Hi Dan,
I've just tried integrating the 2.2.5 in JBossWS-CXF and I see a lot of
failures in our testsuite.
Basically I'm getting an exception from
StaxUtils.createXMLStreamReader(InputSource src) because both byte and
character streams are null. That causes the WSDLManagerImpl to fail in
getting the WSDL Definition.
I still need to perform deep analysis of this, but it seems to me the
point here is that there're situations in which the InputSource got from
the wsdl locator there has the wsdl URL only, so we should not try
getting a document from one of the InputSource's streams.
I tried simply patching the WSDLManagerImpl locally as follows and the
failures went away:
--- rt/core/src/main/java/org/apache/cxf/wsdl11/WSDLManagerImpl.java
(revisione 880686)
+++ rt/core/src/main/java/org/apache/cxf/wsdl11/WSDLManagerImpl.java
(copia locale)
@@ -212,21 +212,26 @@
catLocator,
bus);
InputSource src = wsdlLocator.getBaseInputSource();
- Document doc;
- try {
- doc = StaxUtils.read(StaxUtils.createXMLStreamReader(src),
true);
- if (src.getSystemId() != null) {
- try {
- doc.setDocumentURI(new String(src.getSystemId()));
- } catch (Exception e) {
- // ignore - probably not DOM level 3
- }
- }
- } catch (Exception e) {
- throw new WSDLException(WSDLException.PARSER_ERROR,
e.getMessage(), e);
+ Definition def = null;
+ if (src.getByteStream() != null || src.getCharacterStream() !=
null) {
+ Document doc;
+ try {
+ doc =
StaxUtils.read(StaxUtils.createXMLStreamReader(src), true);
+ if (src.getSystemId() != null) {
+ try {
+ doc.setDocumentURI(new String(src.getSystemId()));
+ } catch (Exception e) {
+ // ignore - probably not DOM level 3
+ }
+ }
+ } catch (Exception e) {
+ throw new WSDLException(WSDLException.PARSER_ERROR,
e.getMessage(), e);
+ }
+
+ def = reader.readWSDL(wsdlLocator, doc.getDocumentElement());
+ } else {
+ def = reader.readWSDL(wsdlLocator);
}
-
- Definition def = reader.readWSDL(wsdlLocator,
doc.getDocumentElement());
synchronized (definitionsMap) {
definitionsMap.put(url, def);
}
All the usecases where I get the exception have a service endpoint
implementation annotated with @WebService( ... ,
wsdlLocation="WEB-INF/wsdl/myWsdl.wsdl", ...)
What's your point on view on this?
Thanks
Alessio
Daniel Kulp wrote:
This is a vote to release CXF 2.2.5
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.2.4 release. Over 90 JIRA issues
are resolved for 2.2.5
List of issues:
The Maven staging area is at:
https://repository.apache.org/content/repositories/orgapachecxf-008/
The distributions are in:
https://repository.apache.org/content/repositories/orgapachecxf-008/org/a
pache/cxf/apache-cxf/2.2.5
This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.5
The vote will be open for 72 hours.
I haven't had time to run the TCK on it yet, so I'll vote later, but I
wanted to get the vote started.
--
Alessio Soldano
Web Service Lead, JBoss
