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
[EMAIL PROTECTED]:
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
