Subject: RE: MTOM with CXF WS-I Validation Failure - msg#00414

List: users-cxf-apache

Date: Prev Next Index Thread: Prev Next Index

It works fine and generates the code with data handlers when we use the
following declaration. Even though we donât import the xmime schema file and by
just having the namespace it works fine. But doesnât pass the WS-I Validation.

<xsd:element name="AppData" type="xsd:base64Binary"
xmime:expectedContentTypes="application/xml,application/zip,application/x-gzip"/>

If we use the xmime types we see that the code that gets generated is of byte
array type .Is it a standard to import/include the xmime schema file ?

Thanks,
bharath

-----Original Message-----
From: Benson Margulies [mailto:bimargulies@xxxxxxxxx]
Sent: Thursday, June 18, 2009 2:33 PM
To: users@xxxxxxxxxxxxxx; bharath.thippireddy@xxxxxxxxxx
Subject: Re: MTOM with CXF WS-I Validation Failure

I did some work to make xmime work in Aegis, and I hit one bug in
JAXB. Certainly your fragment is wrong isofar as it uses
xmime:expectedContentTypes without including that schema. Have you
tried just using JAXB tools and seeing what you get for generated
code?

On Thu, Jun 18, 2009 at 2:26 PM, bharath
thippireddy<bharath.thippireddy@xxxxxxxxxx> wrote:
> In our wsdl files for services which use MTOM we have the following element
> declaration.
>
>
>
> <xsd:element name="AppData" Âtype="xsd:base64Binary"
> xmime:expectedContentTypes="application/xml,application/zip,application/x-gzip"/>
>
>
>
> When we run the WS-I validation against the wsdl it fails with the following
> exception
>
>
>
> Assertion: BP2122
>
>
>
> Result
>
> failed
>
> Failure Message
>
> A wsdl:types element contained a data type definition that is not an XML
> schema definition.
>
> Failure Detail Message
>
> Schema is structurally invalid.
>
> Fatal error: The prefix "xmime" for attribute "xmime:expectedContentTypes"
> associated with an element type "xsd:element" is not bound.
>
>
>
>
>
> The validation passes if we change the type to type="xmime:base64Binary".This
> requires a new xmime schema to be imported.
>
> But the code that gets generated uses byte[] instead of DataHandlers.Looks
> like the wsdl2java ignores the xmime:expectedContentTypes if the type is not Â
> xsd:base64Binary .Is this a bug in CXF?
>
>
>
> What is the recommended Âapproach?
>
>
>
> Thanks and regards,
>
> Bharath
>
>

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: MTOM with CXF WS-I Validation Failure

That's probably a bug in JAXB as we don't really do anything with the schema other than to pass it into JAXB. Most likely, a bug would need to be reported with them: http://jaxb.dev.java.net Dan On Thu June 18 2009 2:26:49 pm bharath thippireddy wrote: > In our wsdl files for services which use MTOM we have the following element > declaration. > > > > <xsd:element name="AppData" type="xsd:base64Binary" > xmime:expectedContentTypes="application/xml,application/zip,application/x-g >zip"/> > > > > When we run the WS-I validation against the wsdl it fails with the > following exception > > > > Assertion: BP2122 > > > > Result > > failed > > Failure Message > > A wsdl:types element contained a data type definition that is not an XML > schema definition. > > Failure Detail Message > > Schema is structurally invalid. > > Fatal error: The prefix "xmime" for attribute "xmime:expectedContentTypes" > associated with an element type "xsd:element" is not bound. > > > > > > The validation passes if we change the type to > type="xmime:base64Binary".This requires a new xmime schema to be imported. > > But the code that gets generated uses byte[] instead of DataHandlers.Looks > like the wsdl2java ignores the xmime:expectedContentTypes if the type is > not xsd:base64Binary .Is this a bug in CXF? > > > > What is the recommended approach? > > > > Thanks and regards, > > Bharath -- Daniel Kulp dkulp@xxxxxxxxxx http://www.dankulp.com/blog

Next Message by Date: click to view message preview

Re: WSDL URL from deployed application

NO idea on that one. Check the classpath/classloader/war/ear/whatever for anything Xerces related or possibly something like an "xml-apis.jar" or similar and try removing them. It sounds like somehow it's getting a different version of the Document interface or something. Really not sure how to resolve that type of thing. Dan On Wed June 17 2009 6:30:50 pm vp2005 wrote: > Hi, > > I am using CXF 2.2.2 for the web service client. I packaged the stubs as > well as the WSDL and schema files into my client jar. I am using > MyClass.class.getResource("/com/mycompany/services/myTest.wsdl") to get the > URL and the same is passed while instantiating the Service. > > MyTestService service = new MyTestService(wsdlURL); > MyTestPortType port = service.getMyTest(); > ( (BindingProvider) port ).getRequestContext().put( > BindingProvider.ENDPOINT_ADDRESS_PROPERTY, > "http://www.mycompany.com/services/myTest" ); > > When I invoked the service from my test client in Eclipse it returned with > the correct response from service. However, when I deployed my application > on WebLogic 9.2 server, it is throwing the following exception: > > java.lang.ClassCastException: > org.apache.xerces.dom.DeferredDocumentTypeImpl at > java.util.XMLUtils.load(XMLUtils.java:61) > at java.util.Properties.loadFromXML(Properties.java:701) > at > org.apache.cxf.common.util.PropertiesLoaderUtils.loadAllProperties(Properti >esLoaderUtils.java:71) at > org.apache.cxf.wsdl11.WSDLManagerImpl.registerInitialExtensions(WSDLManager >Impl.java:224) at > org.apache.cxf.wsdl11.WSDLManagerImpl.registerInitialExtensions(WSDLManager >Impl.java:219) at > org.apache.cxf.wsdl11.WSDLManagerImpl.<init>(WSDLManagerImpl.java:109) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcce >ssorImpl.java:39) at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstru >ctorAccessorImpl.java:27) at > java.lang.reflect.Constructor.newInstance(Constructor.java:494) at > java.lang.Class.newInstance0(Class.java:350) > at java.lang.Class.newInstance(Class.java:303) > at org.apache.cxf.bus.extension.Extension.load(Extension.java:86) > at > org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Extension >ManagerImpl.java:153) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.processExtension(Extensio >nManagerImpl.java:129) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.loadFragment(ExtensionMan >agerImpl.java:122) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl >.java:114) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.<init>(ExtensionManagerIm >pl.java:83) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.<init>(ExtensionManagerIm >pl.java:57) at > org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus >.java:91) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:41) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:37) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:33) at > org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:69) at > org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:106) > at > org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:97) at > org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.ja >va:64) at javax.xml.ws.Service.<init>(Service.java:36) > > When I logged the WSDL URL generated dynamically, I noticed the following > difference : > > WSDL URL from test client (from Eclipse): > > jar:file:/C:.../myTest.wsdl > > WSDL URL from deployed application (on WebLogic server): > > zip:C:/.../myTest.wsdl > > Does it have anything to do with the problem ? > > I have been struggling with this problem for a long time. Any help to > resolve this would be highly appreciated. > > Thanks a lot ! > vp2005 -- Daniel Kulp dkulp@xxxxxxxxxx http://www.dankulp.com/blog

Previous Message by Thread: click to view message preview

Re: MTOM with CXF WS-I Validation Failure

I did some work to make xmime work in Aegis, and I hit one bug in JAXB. Certainly your fragment is wrong isofar as it uses xmime:expectedContentTypes without including that schema. Have you tried just using JAXB tools and seeing what you get for generated code? On Thu, Jun 18, 2009 at 2:26 PM, bharath thippireddy<bharath.thippireddy@xxxxxxxxxx> wrote: > In our wsdl files for services which use MTOM we have the following element > declaration. > > > > <xsd:element name="AppData" Âtype="xsd:base64Binary" > xmime:expectedContentTypes="application/xml,application/zip,application/x-gzip"/> > > > > When we run the WS-I validation against the wsdl it fails with the following > exception > > > > Assertion: BP2122 > > > > Result > > failed > > Failure Message > > A wsdl:types element contained a data type definition that is not an XML > schema definition. > > Failure Detail Message > > Schema is structurally invalid. > > Fatal error: The prefix "xmime" for attribute "xmime:expectedContentTypes" > associated with an element type "xsd:element" is not bound. > > > > > > The validation passes if we change the type to type="xmime:base64Binary".This > requires a new xmime schema to be imported. > > But the code that gets generated uses byte[] instead of DataHandlers.Looks > like the wsdl2java ignores the xmime:expectedContentTypes if the type is not Â > xsd:base64Binary .Is this a bug in CXF? > > > > What is the recommended Âapproach? > > > > Thanks and regards, > > Bharath > >

Next Message by Thread: click to view message preview

Loading Comments...