cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Stapel (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5246) Conflicting schema namespaces for services with same set of schema classes
Date Fri, 30 Aug 2013 09:41:51 GMT

     [ https://issues.apache.org/jira/browse/CXF-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kai Stapel updated CXF-5246:
----------------------------

    Description: 
In case of services, which have the exact same set of schema classes, it may occur that the
generated schema namespace of the server service is different from the generated schema namespace
of the client service, depending on the order of their initialization. This can result in
non-functioning services (see attached sample project). 

Errors like this occur:
{code}
javax.xml.bind.UnmarshalException: unknown type name: {http://bar.service/}barName. Did you
mean {http://foo.service/}barName?
{code}

The cause is the caching of schemas in {{JAXBDatabinding}}, which will reuse a schema if the
set of {{contextClasses}} are equal (see method {{JAXBDatabinding.createJAXBContextAndSchemas()}}
and class {{JAXBContextCache}}). The problem is that it will use the package of the current
service as the target namespace for the schema. So it may happen that the target namespaces
differ between client and server side, depending on the order of initialization of the services
which have an equal set of schema classes.

Our current workaround for this problem is to specify equal target namespaces (e.g. by setting
{{@WebService(targetNamespace = "http://reused.target.namespace")}}) for the affected services
so the order of their initialization does not matter anymore.

Another workaround could be to give each service an individual DataBinding without overlapping
schema types. But that would require extra coding effort on server and client side.

Maybe you could change the key of the {{JAXBCONTEXT_CACHE}} map in the {{JAXBContextCache}}
class to also contain the target namespace (or the schema class) so different services would
get different schemas.

  was:
In case of services, which have the exact same set of schema classes, it may occur that the
generated schema namespace of the server service is different from the generated schema namespace
of the client service, depending on the order of their initialization. This can result in
non-functioning services (see attached sample project). 

Errors like this occur:
{code}
javax.xml.bind.UnmarshalException: unknown type name: {http://bar.service/}barName. Did you
mean {http://foo.service/}barName?
{code}

The cause is the caching of schemas in {{JAXBDatabinding}}, which will reuse a schema if the
set of {{contextClasses}} are equal (see method {{JAXBDatabinding.createJAXBContextAndSchemas()}}
and class {{JAXBContextCache}}). The problem is that it will use the package of the current
service as the target namespace for the schema. So it may happen that the target namespaces
differ between client and server side, depending on the order of initialization of the services
which have an equal set of schema classes.

Our current workaround for this problem is to specify equal target namespaces (e.g. by setting
{{@WebService(targetNamespace = "http://reused.target.namespace")}}) for the affected services
so the order of their initialization does not matter anymore.

Another workaround could be to give each service an individual DataBinding without overlapping
schema types. But that would require extra coding effort on server and client side.

Maybe you could change the key of the {{JAXBCONTEXT_CACHE}} map in the {{JAXBContextCache}}
class to also contain the service name (or class) so different services would get different
schemas.

    
> Conflicting schema namespaces for services with same set of schema classes
> --------------------------------------------------------------------------
>
>                 Key: CXF-5246
>                 URL: https://issues.apache.org/jira/browse/CXF-5246
>             Project: CXF
>          Issue Type: Bug
>          Components: JAXB Databinding
>    Affects Versions: 2.7.6
>         Environment: CXF Services with JAXB Databinding
>            Reporter: Kai Stapel
>            Priority: Minor
>         Attachments: cfx-wrong-namespace.zip
>
>
> In case of services, which have the exact same set of schema classes, it may occur that
the generated schema namespace of the server service is different from the generated schema
namespace of the client service, depending on the order of their initialization. This can
result in non-functioning services (see attached sample project). 
> Errors like this occur:
> {code}
> javax.xml.bind.UnmarshalException: unknown type name: {http://bar.service/}barName. Did
you mean {http://foo.service/}barName?
> {code}
> The cause is the caching of schemas in {{JAXBDatabinding}}, which will reuse a schema
if the set of {{contextClasses}} are equal (see method {{JAXBDatabinding.createJAXBContextAndSchemas()}}
and class {{JAXBContextCache}}). The problem is that it will use the package of the current
service as the target namespace for the schema. So it may happen that the target namespaces
differ between client and server side, depending on the order of initialization of the services
which have an equal set of schema classes.
> Our current workaround for this problem is to specify equal target namespaces (e.g. by
setting {{@WebService(targetNamespace = "http://reused.target.namespace")}}) for the affected
services so the order of their initialization does not matter anymore.
> Another workaround could be to give each service an individual DataBinding without overlapping
schema types. But that would require extra coding effort on server and client side.
> Maybe you could change the key of the {{JAXBCONTEXT_CACHE}} map in the {{JAXBContextCache}}
class to also contain the target namespace (or the schema class) so different services would
get different schemas.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message