Validation problems on a cxf service bundle deployed on FUSE ESB 4.1

[marcelcasado]

Hi,

I have a cxf service "wsdl first" bundle deployed in Fuse ESB 4.1. The service works fine.  When I enable schema validation "". The  service throws a few warnings and exceptions related to wsdl and schema validation  that does not make sense (at least to me) and then it never really validates the request/response. I have the schemas and wsdl validated on Oxygen IDE and soapUI is able to handle wsdl and schemas without a problem. For more that I look I don't see what is wrong. 

I want to post my service bundle but it complains is to large. So I only posted the wsdl and schemas.

02:45:25,421 | INFO  | 5470989@qtp5-0   | FlightHazardsServicePortTypeImpl | FlightHazardsServicePortTypeImpl   47 | Executing operation getFlightHazards

02:45:25,993 | WARN  | 5470989@qtp5-0   | EndpointReferenceUtils           | al.util.DOMEntityResolverWrapper  142 | Could not resolve Schema for ../ERAM_R2_FO/LMTSS_ERAM_flight_plan.xsd

02:45:25,996 | WARN  | 5470989@qtp5-0   | EndpointReferenceUtils           | al.util.DOMEntityResolverWrapper  142 | Could not resolve Schema for ../ERAM_R2_FO/LMATM_CSA_standard_response.xsd

02:45:25,999 | WARN  | 5470989@qtp5-0   | EndpointReferenceUtils           | al.util.DOMEntityResolverWrapper  142 | Could not resolve Schema for ../schemas/flightHazardsService/response_flight_hazards.xsd

02:45:26,012 | WARN  | 5470989@qtp5-0   | EndpointReferenceUtils           | bstractOutDatabindingInterceptor  177 | SAXException for newSchema() on

org.xml.sax.SAXParseException: s4s-elt-invalid-content.1: The content of 'schema' is invalid.  Element 'import' is invalid, misplaced, or occurs too often.

     at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:231)

Thanks in advance,

-Marcel

[mielket]

Hello,

Can you upload your testcase to the following ftp location please?

FTP Server:    ftp-irl.iona.com

Username:      marcelca

Password:      Tutloit_

Direct Upload Link: Upload Link:   ftp://marcelca:[e-mail]

We will look into your testcase then here in-house.

[marcelcasado]

Uploaded onthe ftp source in a zip Eclipse project and the bundle already built

Thanks  Torsten for looking into it.

[mielket]

Looks like I am seeing the same problem here. Full error that I get is in the attached error.txt. Does yours look the same? I am investigating further.

[mielket]

Doing a bit of guessing here since I cannot recompile your testcase (due to dependencies on some internal packages of yours).

The problem might be that the schema files cannot be loaded at runtime for doing the validation. On the file system you have the wsdl file in wsdl/ importing the schema files from ../schemas/ which obviously works ok.

However I believe the OSGI classloading will try to load the schema files based on the configured Bundle-ClassPath (as defined in MANIFEST.MF). In your case the Bundle-ClassPath contains ./, which is the root level OSGI bundle directory. So when trying to load ../schemas/... this will then fail as it tries to load it from ./ the bundles root directory.

I suggest a quick test. Place all schema and wsdl files into one directory and import them using "./" in your wsdl and xsd files. This might work around the problem.

As I said, I am only guessing here as I cannot recompile the testcase myself.

Btw, I ran the CXF 2.2 wsdlvalidator against your schema and wsdl files and it succeeded without problems. So these files should be okay.

[marcelcasado]

Thanks for looking into it. The errors are the same.

I have another service with the same configuration (but different schemas) with schemas in the schemas/ directory and the wsdl in the wsdl/ directory and the schemas are included/imported using ../schemas/...  and the validation works great. But I'll do the test anyway and I'll let you know.

Well I did the test moving schemas into the wsdl dir and using ./ and that made it work. So something weird is going on since ../schemas is working for my other service.

Thanks much,

-Marcel