[jira] [Commented] (CXF-6754) Determin Media Type in Response
[
https://issues.apache.org/jira/browse/CXF-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117022#comment-15117022
]
Sergey Beryozkin commented on CXF-6754:
---
Neal, I've applied your patch with a very minor tweak (check the annotations
only if a wildcard subtype is there).
Sorry I did not pay enough attention to your patch from a start with other
projects being under way. I honestly do not like this spec piece where 406 is
returned, text/star and with a text/plain writer being available, which is a
spec bug but I'm afraid there's a little chance of JAX-RS 2.1 fixing it, so I'd
rather get this issue resolved :-).
Thanks for your effort and please keep the patches coming
Sergey
> Determin Media Type in Response
> ---
>
> Key: CXF-6754
> URL: https://issues.apache.org/jira/browse/CXF-6754
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: JAXRSOutInterceptor.patch
>
>
> @GET
> @Path("text")
> @Produces(value = "text/*")
> public String geText() {
> return "text/* is ok";
> }
> request Accept=text/*
> Per spec 3.8|2
> 2. Gather the set of producible media types P:
> • If the method is annotated with @Produces, set P = fV (method)g where V (t)
> represents the
> values of @Produces on the specified target t.
> • Else if the class is annotated with @Produces, set P = fV (class)g.
> • Else set P = fV (writers)g where ‘writers’ is the set of MessageBodyWriter
> that support the
> class of the returned entity object.
> Check the resource method anno first then class anno, at last check writers.
> So the response code should be 406.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6754) Determin Media Type in Response
[
https://issues.apache.org/jira/browse/CXF-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6754.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
> Determin Media Type in Response
> ---
>
> Key: CXF-6754
> URL: https://issues.apache.org/jira/browse/CXF-6754
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: JAXRSOutInterceptor.patch
>
>
> @GET
> @Path("text")
> @Produces(value = "text/*")
> public String geText() {
> return "text/* is ok";
> }
> request Accept=text/*
> Per spec 3.8|2
> 2. Gather the set of producible media types P:
> • If the method is annotated with @Produces, set P = fV (method)g where V (t)
> represents the
> values of @Produces on the specified target t.
> • Else if the class is annotated with @Produces, set P = fV (class)g.
> • Else set P = fV (writers)g where ‘writers’ is the set of MessageBodyWriter
> that support the
> class of the returned entity object.
> Check the resource method anno first then class anno, at last check writers.
> So the response code should be 406.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6754) Determin Media Type in Response
[
https://issues.apache.org/jira/browse/CXF-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117033#comment-15117033
]
Neal Hu commented on CXF-6754:
--
It's ok. I do agree the spec is not elegant enough. However we need pass the
TCK. Thanks for your time.
Neal
> Determin Media Type in Response
> ---
>
> Key: CXF-6754
> URL: https://issues.apache.org/jira/browse/CXF-6754
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: JAXRSOutInterceptor.patch
>
>
> @GET
> @Path("text")
> @Produces(value = "text/*")
> public String geText() {
> return "text/* is ok";
> }
> request Accept=text/*
> Per spec 3.8|2
> 2. Gather the set of producible media types P:
> • If the method is annotated with @Produces, set P = fV (method)g where V (t)
> represents the
> values of @Produces on the specified target t.
> • Else if the class is annotated with @Produces, set P = fV (class)g.
> • Else set P = fV (writers)g where ‘writers’ is the set of MessageBodyWriter
> that support the
> class of the returned entity object.
> Check the resource method anno first then class anno, at last check writers.
> So the response code should be 406.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
Neal Hu created CXF-6759: Summary: WADL2JAVA Tools Generated Source has Duplicate Method Name Key: CXF-6759 URL: https://issues.apache.org/jira/browse/CXF-6759 Project: CXF Issue Type: Bug Components: JAX-RS, Tooling Affects Versions: 3.1.4, 3.0.7 Environment: Windows Reporter: Neal Hu Fix For: 3.1.5, 3.0.8, 3.2.0 Generate source using below wadl file contains duplicate method name: http://wadl.dev.java.net/2009/02"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> http://localhost:9088/Pojo/hello/";> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neal Hu updated CXF-6759:
-
Description:
Generate source using below wadl file contains duplicate method name:
command: wadl2java.bat -p cxf -d . -impl hello.wadl
http://wadl.dev.java.net/2009/02";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
http://localhost:9088/Pojo/hello/";>
/**
* Created by Apache CXF WadlToJava code generator
**/
package cxf;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
@Path("/BasicResource")
public class BasicResourceResource {
@GET
@Produces("application/json")
@Path("/echo")
public String getEcho() {
//TODO: implement
return null;
}
@GET
@Produces("text/plain")
@Path("/echo")
public String getEcho() {
//TODO: implement
return null;
}
}
was:
Generate source using below wadl file contains duplicate method name:
http://wadl.dev.java.net/2009/02";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
http://localhost:9088/Pojo/hello/";>
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117451#comment-15117451
]
Neal Hu commented on CXF-6759:
--
we can add below in SourceGenerator:796
genMethodName = genMethodName.replace("-", "");
int count = 1;
String name = genMethodName;
while (sbMethodCode.indexOf(methodName) != -1) {
name = genMethodName + count++;
}
sbMethodCode.append(name);
I will keep working on the patch if you think this fix in valid.
Thanks.
Neal
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117506#comment-15117506
]
Sergey Beryozkin commented on CXF-6759:
---
Hi Neal
Indeed, if no method ids are used and we have multiple same path methods under
a given resource then I see it will generate duplicate methods as it has no
other info to make the names unique.
I agree the counter is the way to go in such cases.
See, if we check the buffer then we will have to calculate the index right
which can be tricky as there might be some parameters with the same name, etc.
How about:
- line 510, this is where a new resource class generation starts, just before
writeMethods() is called, create Map of String to Integer and pass it to
writeMethods -> writeResourceMethod and simply check and increase the counter
there if the same name method already exists.
Do you agree ?
Sergey
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6760) extract swagger2 feature in its own module
Romain Manni-Bucau created CXF-6760: --- Summary: extract swagger2 feature in its own module Key: CXF-6760 URL: https://issues.apache.org/jira/browse/CXF-6760 Project: CXF Issue Type: Bug Affects Versions: 3.1.4 Reporter: Romain Manni-Bucau the feature is not provided *with*dependencies so if cxf is in the container and swagger the webapp then it leads very easily to issues. Having an external module would make it smoother for integrations and doesnt really hurt CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6761) JAX-RS ClientImpl does not set TLSClientParameters on HTTPConduit when only HostnameVerifier is configured
Chris Ribble created CXF-6761:
-
Summary: JAX-RS ClientImpl does not set TLSClientParameters on
HTTPConduit when only HostnameVerifier is configured
Key: CXF-6761
URL: https://issues.apache.org/jira/browse/CXF-6761
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.4
Reporter: Chris Ribble
Priority: Minor
org.apache.cxf.jaxrs.client.spec.ClientImpl only copies the TLSClientParameters
configured by ClientBuilder.newBuilder().hostnameVerifier(HostnameVerifier) if
an SSLSocketFactory or TrustManagers are configured.
This makes it impossible to use a custom HostnameVerifier without also
declaring a custom SSLSocketFactory or TrustManagers.
Snip of incorrect code from
rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/spec/ClientImpl.java,
line 282
{code}
// TLS
TLSClientParameters tlsParams = secConfig.getTlsClientParams();
if (tlsParams.getSSLSocketFactory() != null
|| tlsParams.getTrustManagers() != null) {
clientCfg.getHttpConduit().setTlsClientParameters(tlsParams);
}
{code}
Proposed replacement:
{code}
// TLS
TLSClientParameters tlsParams = secConfig.getTlsClientParams();
if (tlsParams.getSSLSocketFactory() != null
|| tlsParams.getTrustManagers() != null
|| tlsParams.getHostnameVerifier() != null) {
clientCfg.getHttpConduit().setTlsClientParameters(tlsParams);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118447#comment-15118447
]
Andriy Redko commented on CXF-6740:
---
Hey Aki,
You are very right, the patch to Swagger *does not solve* the problem, I
honestly have troubles to understand the overall picture, as it partially
addresses one specific use case, it looks broken to me. Anyway, I am going to
work on Swagger side to fix this issue, although we could do some workaround in
CXF, I think the complete solution would be better (if you already have
something with this regards, please share). Thanks!
Best Regards,
Andriy Redko
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
Chris Ribble created CXF-6762: - Summary: DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries Key: CXF-6762 URL: https://issues.apache.org/jira/browse/CXF-6762 Project: CXF Issue Type: Bug Components: JAX-RS, Transports Affects Versions: 3.1.4 Reporter: Chris Ribble Priority: Minor DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder implementation in CXF (and which cannot be overridden without also overriding the SSLContext, due to CXF-6761) improperly validates the request hostname against the DNSName values from the SAN section of a certificate when matching wildcards. For example, the following works: Hostname = my.test.com -> DNSName = *.test.com But the following does not: Hostname = 1.my.test.com -> DNSName = *.my.test.com The reason this fails is that the validation code erroneously assumes (in multiple places) that wildcards only ever exist on the root domain. The logic should be improved to allow the wildcard to be used to replace 1 domain name component or component fragment (comments in the code indicate that this is its purpose, but it fails at this). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
[ https://issues.apache.org/jira/browse/CXF-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Ribble updated CXF-6762: -- Remaining Estimate: 48h (was: 24h) Original Estimate: 48h (was: 24h) > DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries > --- > > Key: CXF-6762 > URL: https://issues.apache.org/jira/browse/CXF-6762 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Transports >Affects Versions: 3.1.4 >Reporter: Chris Ribble >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder > implementation in CXF (and which cannot be overridden without also overriding > the SSLContext, due to CXF-6761) improperly validates the request hostname > against the DNSName values from the SAN section of a certificate when > matching wildcards. > For example, the following works: > Hostname = my.test.com -> DNSName = *.test.com > But the following does not: > Hostname = 1.my.test.com -> DNSName = *.my.test.com > The reason this fails is that the validation code erroneously assumes (in > multiple places) that wildcards only ever exist on the root domain. > The logic should be improved to allow the wildcard to be used to replace 1 > domain name component or component fragment (comments in the code indicate > that this is its purpose, but it fails at this). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118628#comment-15118628
]
Daniel Kulp commented on CXF-6758:
--
This is working as design. The gMonth is described at:
https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#gMonth
and in this case should be in the XML as "--07". Thus, the XML is invalid
according to the schema and should be rejected. IMO, the reference
implementation should also reject it as its invalid.
That said, you can turn this off in CXF by setting the
"set-jaxb-validation-event-handler" property on the endpoint to "false".
> DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar
> parse error of severity ValidationEvent.ERROR
> --
>
> Key: CXF-6758
> URL: https://issues.apache.org/jira/browse/CXF-6758
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
> Environment: CXF 3.1.4 integrated into JBoss Wildly 10.0.0.CR5, java
> version 1.8.0_71
>Reporter: Thorsten Möller
>
> The implementation of
> {{org.apache.cxf.jaxb.io.DataReaderImpl.handleEvent(ValidationEvent event)}}
> is too strict in comparison to
> {{com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleEvent(ValidationEvent)}}
> and returns {{false}} (cannot recover) if the {{ValidationEvent.severity}}
> equals {{ValidationEvent.ERROR}}.
> In the following, details from a real-world Web service where we have
> encountered this issue.
> The issue can be observed when invoking the method {{GetListModel}} of this
> [Web service|http://webservices.eurotaxglass.com/wsdl/identification-v2.wsdl]
> whose reply message contains elements of the complex type {{ETGdateType}}
> that contains a field of type {{xsd:gMonth}} (and {{xsd:gYear}}). The
> following is an excerpt of the relevant part of a reply message:
> {code:xml}
>
> 07
> 2010
>
> {code}
> If invoked by a service client class from within a Web application deployed
> to Wildfly (which uses CXF), an unmarshalling error occurs and the following
> stack trace is logged:
> {noformat}
> 16:43:46,891 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default
> task-113) Interceptor for
> {http://www.eurotax.com/Webservices/Identification/}IdentificationStub#{http://www.eurotax.com/Webservices/Identification/}GetListModel
> has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault:
> Unmarshalling Error: 07
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:905)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
> at
> ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:277)
> at
> ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
> at
> ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
> Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMetho
