You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by jsolderitsch <ja...@accenture.com> on 2008/06/09 21:40:09 UTC
cxf generation error: Thrown by JAXB : 'CryptoBinary' is already
defined
I have a wsdl that refers to a external schema. The latter imports another
schema like this:
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
This xmldsig-core-schema.xsd is located in the same folder that the wsdl and
the parent schema are located.
If I run maven to generate code, I get:
Jun 9, 2008 3:28:40 PM
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
destroySingletons
INFO: Destroying singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@4d75f5:
defining beans
[cxf,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceManager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManager,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsdl.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workqueue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,org.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.jaxws.context.WebServiceContextResourceResolver,org.apache.cxf.jaxws.context.WebServiceContextImpl,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.binding.xml.XMLBindingFactory,org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder,org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory];
root of factory hierarchy
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Thrown by JAXB : 'CryptoBinary' is already defined
Now, if I change the import to be:
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
I no longer get the generation error. Why would the full form of the
schemaLocation not lead to the error but the local version does? Is this
schema somehow already part of cxf so that I do not need the import?
The wsdl and xsd files come from a third-party and I would rather leave them
in tact if possible.
Thanks for any advice.
Jim
--
View this message in context: http://www.nabble.com/cxf-generation-error%3A-Thrown-by-JAXB-%3A-%27CryptoBinary%27-is-already-defined-tp17740140p17740140.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf generation error: Thrown by JAXB : 'CryptoBinary' is
already defined
Posted by jsolderitsch <ja...@accenture.com>.
Solved, I think.
In the wsdl that references the schema we have a security import:
<import
namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
schemaLocation="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
/>
This itself includes the xmldsig stuff and so strictly speaking, we are
asking for this sub-schema a second time. The element CryptoBinary is indeed
already defined in my case.
The security add-on is being layered on top of the customer wsdl by my team
in anticipation of needing to add support for saml assertions and the
customer wsdl may eventually also do away with this secondary import when
its wsdl is updated.
So I think the answer for now is to comment out the xsd import line that
does the import.
But thanks for the quick suggestion.
dkulp wrote:
>
>
> Hmm... possible. We have a copy of the xmldsig-core-schema.xsd in
> the jar. Most likely that affects the SECOND case though, not the
> first case. The internal catalog we use maps the full version into
> the what's needed in the jar. Thus, the second one would probably be
> using our internal copy. Generally, that's the better way to
> go. Use the full url in the import, then use a catalog to map it to
> a local copy.
>
> In anycase, I'm not sure why you would be getting that error unless
> the xmldsig-core-schema.xsd you have is corrupt or something. Not
> really sure though. Maybe try the command line tools (instead of
> maven) to see if that behaves differently?
>
> Dan
>
>
>
> On Jun 9, 2008, at 3:40 PM, jsolderitsch wrote:
>
>>
>> I have a wsdl that refers to a external schema. The latter imports
>> another
>> schema like this:
>>
>> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
>> schemaLocation="xmldsig-core-schema.xsd"/>
>>
>> This xmldsig-core-schema.xsd is located in the same folder that the
>> wsdl and
>> the parent schema are located.
>>
>> If I run maven to generate code, I get:
>>
>> Jun 9, 2008 3:28:40 PM
>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
>> destroySingletons
>> INFO: Destroying singletons in
>> org
>> .springframework
>> .beans.factory.support.DefaultListableBeanFactory@4d75f5:
>> defining beans
>> [cxf,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.
>> bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceM
>> anager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.
>> BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManag
>> er,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsd
>> l.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workque
>> ue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,or
>> g.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.jaxws.context.WebServiceContextResourceResolver,org.apache.cxf.jaxws.context.WebServiceContextImpl,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.binding.xml.XMLBindingFactory,org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder,org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory];
>> root of factory hierarchy
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Thrown by JAXB : 'CryptoBinary' is already defined
>>
>> Now, if I change the import to be:
>>
>> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
>> schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
>> "/>
>>
>> I no longer get the generation error. Why would the full form of the
>> schemaLocation not lead to the error but the local version does? Is
>> this
>> schema somehow already part of cxf so that I do not need the import?
>>
>> The wsdl and xsd files come from a third-party and I would rather
>> leave them
>> in tact if possible.
>>
>> Thanks for any advice.
>>
>> Jim
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/cxf-generation-error%3A-Thrown-by-JAXB-%3A-%27CryptoBinary%27-is-already-defined-tp17740140p17740140.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/cxf-generation-error%3A-Thrown-by-JAXB-%3A-%27CryptoBinary%27-is-already-defined-tp17740140p17740738.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf generation error: Thrown by JAXB : 'CryptoBinary' is already defined
Posted by Daniel Kulp <dk...@apache.org>.
Hmm... possible. We have a copy of the xmldsig-core-schema.xsd in
the jar. Most likely that affects the SECOND case though, not the
first case. The internal catalog we use maps the full version into
the what's needed in the jar. Thus, the second one would probably be
using our internal copy. Generally, that's the better way to
go. Use the full url in the import, then use a catalog to map it to
a local copy.
In anycase, I'm not sure why you would be getting that error unless
the xmldsig-core-schema.xsd you have is corrupt or something. Not
really sure though. Maybe try the command line tools (instead of
maven) to see if that behaves differently?
Dan
On Jun 9, 2008, at 3:40 PM, jsolderitsch wrote:
>
> I have a wsdl that refers to a external schema. The latter imports
> another
> schema like this:
>
> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
> schemaLocation="xmldsig-core-schema.xsd"/>
>
> This xmldsig-core-schema.xsd is located in the same folder that the
> wsdl and
> the parent schema are located.
>
> If I run maven to generate code, I get:
>
> Jun 9, 2008 3:28:40 PM
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
> destroySingletons
> INFO: Destroying singletons in
> org
> .springframework
> .beans.factory.support.DefaultListableBeanFactory@4d75f5:
> defining beans
> [cxf,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.
> bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceM
> anager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.
> BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManag
> er,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsd
> l.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workque
> ue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,or
> g.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.jaxws.context.WebServiceContextResourceResolver,org.apache.cxf.jaxws.context.WebServiceContextImpl,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.binding.xml.XMLBindingFactory,org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder,org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory];
> root of factory hierarchy
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Thrown by JAXB : 'CryptoBinary' is already defined
>
> Now, if I change the import to be:
>
> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
> schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
> "/>
>
> I no longer get the generation error. Why would the full form of the
> schemaLocation not lead to the error but the local version does? Is
> this
> schema somehow already part of cxf so that I do not need the import?
>
> The wsdl and xsd files come from a third-party and I would rather
> leave them
> in tact if possible.
>
> Thanks for any advice.
>
> Jim
>
>
>
> --
> View this message in context: http://www.nabble.com/cxf-generation-error%3A-Thrown-by-JAXB-%3A-%27CryptoBinary%27-is-already-defined-tp17740140p17740140.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog