[jira] [Created] (CXF-6745) Relative Schema includes/imports in WSDL are not working (becoming absolute which is a problem behind a proxy)
Thomas Hackel created CXF-6745:
--
Summary: Relative Schema includes/imports in WSDL are not working
(becoming absolute which is a problem behind a proxy)
Key: CXF-6745
URL: https://issues.apache.org/jira/browse/CXF-6745
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.4
Reporter: Thomas Hackel
In the (contract first/human created) WSDL there is a relative import
{code:xml}
{code}
When accessing the Services and retrieving the related WSDL the location is
being replaced by an absolute address:
{code:xml}
http://10.1.2.3:8080/app/mappedservice?xsd=MyTypes.xsd"/>
{code}
It should be relative like:
{code:xml}
{code}
This is a problem especially behind a proxy service.
The service creator does not know the "final" absolute address of the
WSDL/Schema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095880#comment-15095880 ] iris ding commented on CXF-6729: HI Sergy, It seems I lack of related authority to commit the chagnes: g:\gitcxfnew\cxf>git push origin master Username for 'https://git-wip-us.apache.org': irisdingbj Password for 'https://irisdin...@git-wip-us.apache.org': fatal: Authentication failed for 'https://git-wip-us.apache.org/repos/asf/cxf.git/' My github id is: "irisdin...@gmail.com" but my JIRA id is "irisding" Is this the reason that the two id is not the same? Can you please take a look and let me know how I can proceed? Thanks. Iris Ding > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > 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 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095912#comment-15095912 ] Jan Bernhardt commented on FEDIZ-140: - Thanks a lot!! > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096090#comment-15096090 ] Sergey Beryozkin commented on CXF-6729: --- Hi, first do (which you have already done) git clone https://git-wip-us.apache.org/repos/asf/cxf.git and then commit your changes, using your Apache committer id and password Cheers, Sergey > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > 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 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6746) CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
Artiom created CXF-6746:
---
Summary: CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
Key: CXF-6746
URL: https://issues.apache.org/jira/browse/CXF-6746
Project: CXF
Issue Type: Bug
Components: Integration, JAX-RS
Affects Versions: 3.1.4
Environment: java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
3.1.4
com.fasterxml.jackson.jaxrs
jackson-jaxrs-json-provider
2.6.4
org.apache.cxf
cxf-rt-frontend-jaxws
${version.cxf}
org.apache.cxf
cxf-rt-frontend-jaxrs
${version.cxf}
org.apache.cxf
cxf-rt-transports-http
${version.cxf}
org.apache.cxf
cxf-rt-transports-http-jetty
${version.cxf}
org.apache.cxf
cxf-rt-rs-extension-providers
${version.cxf}
org.apache.cxf
cxf-rt-rs-client
${version.cxf}
Reporter: Artiom
I observe some poblem during using JacksonJsonProvider.
Firstly we have CXF v. 2.7.15 and using default Jettison provider.
>From some reasons (Jettison convert POJO String field to "json-number" if it's
>possible,
>http://stackoverflow.com/questions/22379082/jettison-string-returned-as-integer-when-marshalling)
> we decide change provider on JacksonJsonProvider.
I change Jettison on JacksonJsonProvider v. 2.6.4 and observe some problem,
application frozen after some time if we active use new provider.
Because CXF v. 2.7.15 is too older, we decide change CXF version on latest 3.1.4
After change version of CXF I observe that CXF use default Jettison proveder
insted of JacksonJsonProvider despite the fact that in I configurate CXF for
using JacksonJsonProvider. If I only change version of JacksonJsonProvider on
2.0.0 all works fine.
Result:
*CXF v.2.7.15 with Jackson v.2.6.4 work, but have some bug (don't descride them
because v.2.7.15 is too old).*
*CXF v.3.1.4 with Jackson v.2.6.4 doesn't work, CXF use default Jettison.*
*CXF v.3.1.4 with Jackson v.2.0.0 work fine.*
If you need some additional information please write here, thank you.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods
[ https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096190#comment-15096190 ] Christian Schneider commented on CXF-6737: -- I think I found the problem. You need to use JaxWsProxyFactoryBean to create the client if it is JAX-WS. The GreeterService is also not a good example as the interface does not seem to be fully working for JAX-WS. Better try this with a simpler interface. JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean(); factory.setServiceClass(cls); factory.setAddress(url); factory.setWsdlURL(url + "?wsdl"); return (T)factory.create(); > ClientProxyFactoryBean doesn't work with void methods > - > > Key: CXF-6737 > URL: https://issues.apache.org/jira/browse/CXF-6737 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: DOSGi 1.7.0 >Reporter: Amichai Rothman > Attachments: bad_client_example.diff, bad_client_example.diff > > > I'm trying to use a simple ClientProxyFactoryBean to connect to a > dosgi-exported service. Without specifying the wsdl url, it doesn't work > since apparently the method argument names don't match (arg0 vs actual > parameter name, as explained in CXF-897), so I added the wsdl url. Now > service methods that have a return value seem to work ok, but those with void > return type do not. > Further investigation suggests that the issue might be in > ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning > (no method for op) instead of binding the operation, because > initializeClassInfo returns false, because initializeParameter called with > the return type (near the bottom of initializeClassInfo) returns false, since > o.getOutput().getMessagePart/getMessagePartByIndex return null (since there > are no parts - the method can throw an exception, for which the output > message exists, but there is no actual return type). > A quick test in the debugger shows that if I manipulate the flow manually > (e.g. execute the if caluse in initializeWSDLOperation after > initializeClassInfo returns) then the method invocation works ok. > I am not familiar with the inner workings of WSDL or these classes, so I'm > not sure what is the correct place to apply a fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5716) CXF build fails with JDK 1.8
[ https://issues.apache.org/jira/browse/CXF-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096191#comment-15096191 ] Dennis Kieselhorst commented on CXF-5716: - Seems to be fixed now so the issue can be resolved. > CXF build fails with JDK 1.8 > > > Key: CXF-5716 > URL: https://issues.apache.org/jira/browse/CXF-5716 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: Windows > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) >Reporter: Przemyslaw Bielicki > Attachments: console.out > > > [WARNING] Exception in thread "main" java.lang.AssertionError: > org.xml.sax.SAXParseException; systemId: > jar:file:/D:/m2repo/com/sun/xml/bind/jaxb-xjc/2.2.7/jaxb-xjc-2.2.7.jar!/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; > lineNumber: 52; columnNumber: 88; schema_reference: Failed to read schema > document 'xjc.xsd', because 'file' access is not allowed due to restriction > set by the accessExternalSchema property. > [WARNING] at > com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:80) > [WARNING] at > com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl$1$1.startElement(AnnotationParserFactoryImpl.java:118) > [WARNING] at > com.sun.xml.xsom.impl.parser.state.NGCCRuntime.startElement(NGCCRuntime.java:253) > [WARNING] at > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > [WARNING] at > com.sun.tools.xjc.util.SubtreeCutter.startElement(SubtreeCutter.java:108) > [WARNING] at > com.sun.tools.xjc.reader.ExtensionBindingChecker.startElement(ExtensionBindingChecker.java:150) > [WARNING] at > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > [WARNING] at > com.sun.tools.xjc.reader.xmlschema.parser.IncorrectNamespaceURIChecker.startElement(IncorrectNamespaceURIChecker.java:128) > [WARNING] at > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > [WARNING] at > com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.startElement(CustomizationContextChecker.java:193) > [WARNING] at > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551) > [WARNING] at > com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.startElement(DOMForestScanner.java:147) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:244) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250) > [WARNING] at > com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127) > [WARNING] at > com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92) > [WARNING] at > com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100) > [WARNING] at > com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104) > [WARNING] at > com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:269) > [WARNING] at > com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347) > [WARNING] at > com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:128) > [WARNING] at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:168) > [WARNING] at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:157) > [WARNING] at > com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:534) > [WARNING] at > com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:269) > [WARNING] at > com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:95) > [WARNING] at > org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:460) > [WARNING] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:714) > [WARNING] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:270) > [WARNING] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execu
[jira] [Resolved] (CXF-6745) Relative Schema includes/imports in WSDL are not working (becoming absolute which is a problem behind a proxy)
[
https://issues.apache.org/jira/browse/CXF-6745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Hackel resolved CXF-6745.
Resolution: Won't Fix
Each endpoint can be configured by it's final address (PublishedEndpointUrl).
Its configured/created during startup time where my original request would
required a "per request" approach.
So i need to know the external "base url" of the system during start up phase.
Luckly i already have such a property in the application configuration.
> Relative Schema includes/imports in WSDL are not working (becoming absolute
> which is a problem behind a proxy)
> --
>
> Key: CXF-6745
> URL: https://issues.apache.org/jira/browse/CXF-6745
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Thomas Hackel
>
> In the (contract first/human created) WSDL there is a relative import
> {code:xml}
>
> {code}
> When accessing the Services and retrieving the related WSDL the location is
> being replaced by an absolute address:
> {code:xml}
> schemaLocation="http://10.1.2.3:8080/app/mappedservice?xsd=MyTypes.xsd"/>
> {code}
> It should be relative like:
> {code:xml}
>
> {code}
> This is a problem especially behind a proxy service.
> The service creator does not know the "final" absolute address of the
> WSDL/Schema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6746) CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
[
https://issues.apache.org/jira/browse/CXF-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096303#comment-15096303
]
Sergey Beryozkin commented on CXF-6746:
---
I've updated the Jackson version, see
http://git-wip-us.apache.org/repos/asf/cxf/commit/8f98be8e
and CXF tests run OK.
What is likely happening is that you have some beans that both Jettison and
Jackson can handle, example, it is XMLRootElement annotated beans. CXF 3.1.x is
more compliant in the way it selects providers. Jackson is a wildcard provider,
it has wildcard Produces/Consumes, while the default CXF Jettision based
provider is more specific in its Produces/Consumes - hence when both providers
are loaded and both can handle the given data Jettison will win.
Exclude Jettison and it will work as expected, if not - please create a Maven
based test case
> CXF 3.1.4 doesn't work with JacksonJsonProvider 2.6.4
> -
>
> Key: CXF-6746
> URL: https://issues.apache.org/jira/browse/CXF-6746
> Project: CXF
> Issue Type: Bug
> Components: Integration, JAX-RS
>Affects Versions: 3.1.4
> Environment: java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> 3.1.4
>
> com.fasterxml.jackson.jaxrs
> jackson-jaxrs-json-provider
> 2.6.4
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxws
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-transports-http
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-transports-http-jetty
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-rs-extension-providers
> ${version.cxf}
>
>
> org.apache.cxf
> cxf-rt-rs-client
> ${version.cxf}
>
>Reporter: Artiom
>
> I observe some poblem during using JacksonJsonProvider.
> Firstly we have CXF v. 2.7.15 and using default Jettison provider.
> From some reasons (Jettison convert POJO String field to "json-number" if
> it's possible,
> http://stackoverflow.com/questions/22379082/jettison-string-returned-as-integer-when-marshalling)
> we decide change provider on JacksonJsonProvider.
> I change Jettison on JacksonJsonProvider v. 2.6.4 and observe some problem,
> application frozen after some time if we active use new provider.
> Because CXF v. 2.7.15 is too older, we decide change CXF version on latest
> 3.1.4
> After change version of CXF I observe that CXF use default Jettison proveder
> insted of JacksonJsonProvider despite the fact that in I configurate CXF for
> using JacksonJsonProvider. If I only change version of JacksonJsonProvider on
> 2.0.0 all works fine.
> Result:
> *CXF v.2.7.15 with Jackson v.2.6.4 work, but have some bug (don't descride
> them because v.2.7.15 is too old).*
> *CXF v.3.1.4 with Jackson v.2.6.4 doesn't work, CXF use default Jettison.*
> *CXF v.3.1.4 with Jackson v.2.0.0 work fine.*
> If you need some additional information please write here, thank you.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6744) Exceptions thrown from methods annotated with @Suspended result in no response at all
[ https://issues.apache.org/jira/browse/CXF-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6744. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.2.0 3.0.8 3.1.5 thanks for the test > Exceptions thrown from methods annotated with @Suspended result in no > response at all > - > > Key: CXF-6744 > URL: https://issues.apache.org/jira/browse/CXF-6744 > Project: CXF > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Sergey Beryozkin > Fix For: 3.1.5, 3.0.8, 3.2.0 > > > I am about to push a commit with an ignored test that fails because of the > issue described in the title. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6747) XSD to Java problem with enums
Dusan Slivka created CXF-6747:
-
Summary: XSD to Java problem with enums
Key: CXF-6747
URL: https://issues.apache.org/jira/browse/CXF-6747
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 3.0.1
Reporter: Dusan Slivka
Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
different from wsdl on input, if there are enums used. For example, I have the
folowing XSD type in source wsdl:
{code:xml}
{code}
which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
{code:java}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "DigestType", propOrder = {
"digestValue",
"digestType"
})public class DigestType {
protected String digestValue;
@XmlSchemaType(name = "string") // WHY??
protected ChecksumType digestType;
}
{code}
And resulting wsdl for published service looks like this:
{code:xml}
{code}
The problem is caused by @XmlSchemaType(name = "string") annotation. I think
resulting wsdl should be equal to source wsdl.
See also:
[https://github.com/gf-metro/jaxb/issues/21]
[http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6747) XSD to Java problem with enums
[
https://issues.apache.org/jira/browse/CXF-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dusan Slivka updated CXF-6747:
--
Description:
Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
different from wsdl on input, if there are enums used. For example, I have the
folowing XSD type in source wsdl:
{code:xml}
{code}
which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
{code:java}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "DigestType", propOrder = {
"digestValue",
"digestType"
})public class DigestType {
protected String digestValue;
@XmlSchemaType(name = "string") // WHY??
protected ChecksumType digestType;
}
{code}
And resulting wsdl for published service looks like this:
{code:xml}
{code}
The problem is caused by @XmlSchemaType(name = "string") annotation. I think
resulting wsdl should be equal to source wsdl.
See also:
[https://github.com/gf-metro/jaxb/issues/21]
[http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
was:
Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
different from wsdl on input, if there are enums used. For example, I have the
folowing XSD type in source wsdl:
{code:xml}
{code}
which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
{code:java}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "DigestType", propOrder = {
"digestValue",
"digestType"
})public class DigestType {
protected String digestValue;
@XmlSchemaType(name = "string") // WHY??
protected ChecksumType digestType;
}
{code}
And resulting wsdl for published service looks like this:
{code:xml}
{code}
The problem is caused by @XmlSchemaType(name = "string") annotation. I think
resulting wsdl should be equal to source wsdl.
See also:
[https://github.com/gf-metro/jaxb/issues/21]
[http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
> XSD to Java problem with enums
> --
>
> Key: CXF-6747
> URL: https://issues.apache.org/jira/browse/CXF-6747
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.0.1
>Reporter: Dusan Slivka
>
> Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
> different from wsdl on input, if there are enums used. For example, I have
> the folowing XSD type in source wsdl:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
> {code:java}
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "DigestType", propOrder = {
> "digestValue",
> "digestType"
> })public class DigestType {
> protected String digestValue;
> @XmlSchemaType(name = "string") // WHY??
> protected ChecksumType digestType;
> }
> {code}
> And resulting wsdl for published service looks like this:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is caused by @XmlSchemaType(name = "string") annotation. I think
> resulting wsdl should be equal to source wsdl.
> See also:
> [https://github.com/gf-metro/jaxb/issues/21]
> [http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097506#comment-15097506 ] iris ding commented on CXF-6729: Thanks Sergey. I finally committed them using id "543644a". Hope I do not mess anything up. > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > 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 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
