[jira] [Commented] (CXF-5492) ThreadLoad org.apache.cxf.BusFactory.BusHolder leak in Tomcat
[
https://issues.apache.org/jira/browse/CXF-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839480#comment-15839480
]
Roman Proshin commented on CXF-5492:
I have the same problem: when I'm stopping the Tomcat 8.5.9 server with my
application (that uses Apache CXF 3.1.9) I get next 'severe' messages:
{noformat}
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@119f80ac]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@1998c335]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
{noformat}
> ThreadLoad org.apache.cxf.BusFactory.BusHolder leak in Tomcat
> -
>
> Key: CXF-5492
> URL: https://issues.apache.org/jira/browse/CXF-5492
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.7.6, 2.7.8, 2.7.14
> Environment: oracle jdk 7, windows7 x64
>Reporter: Alex O'Ree
>
> Upon web application redeploy (that calls a web service), I've been getting a
> number of log warnings when either Tomcat shutdown's down or when the web app
> is redeployed
> Jan 12, 2014 10:12:28 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: A web application created a ThreadLocal with key of type [null]
> (value [com.sun.xml.bind.v2.ClassFactory$1@fb0bc
> 0e]) and a value of type [java.util.WeakHashMap] (value [{class
> org.uddi.api_v3.BusinessList=java.lang.ref.WeakReference
> @1c0a432e, class
> org.uddi.api_v3.BusinessInfo=java.lang.ref.WeakReference@65c08f63, class
> org.uddi.api_v3.BusinessInfos=
> java.lang.ref.WeakReference@4505e0c5, class
> org.uddi.api_v3.Description=java.lang.ref.WeakReference@4e7c8ea, class org.u
> ddi.api_v3.Name=java.lang.ref.WeakReference@d377d2a, class
> org.uddi.api_v3.ServiceInfo=java.lang.ref.WeakReference@35fa5
> 72d, class java.util.ArrayList=java.lang.ref.WeakReference@4671670a, class
> javax.xml.bind.annotation.W3CDomHandler=java.
> lang.ref.WeakReference@3f23e5a7, class
> org.uddi.api_v3.ListDescription=java.lang.ref.WeakReference@4dba5753, class
> org.u
> ddi.api_v3.ServiceInfos=java.lang.ref.WeakReference@4bb3203}]) but failed to
> remove it when the web application was stop
> ped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
> Jan 12, 2014 10:12:28 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: A web application created a ThreadLocal with key of type
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1
> dd06562]) and a value of type [org.apache.cxf.BusFactory.BusHolder] (value
> [org.apache.cxf.BusFactory$BusHolder@5cb01438
> ]) but failed to remove it when the web application was stopped. To prevent a
> memory leak, the ThreadLocal has been forc
> ibly removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-5492) ThreadLoad org.apache.cxf.BusFactory.BusHolder leak in Tomcat
[
https://issues.apache.org/jira/browse/CXF-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839480#comment-15839480
]
Roman Proshin edited comment on CXF-5492 at 1/26/17 9:47 AM:
-
I have the same problem: when I'm stopping the Tomcat 8.5.9 server with my
application (that uses Apache CXF 3.1.9) I get next 'severe' messages:
{noformat}
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@119f80ac]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@1998c335]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
{noformat}
P.S.
Java version is: 1.8.0_121-b13
OS: Windows 10 x64
was (Author: proshin_roman):
I have the same problem: when I'm stopping the Tomcat 8.5.9 server with my
application (that uses Apache CXF 3.1.9) I get next 'severe' messages:
{noformat}
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@119f80ac]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
26-Jan-2017 12:35:18.941 SEVERE [localhost-startStop-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ROOT] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5af51815]) and a value of
type [org.apache.cxf.BusFactory.BusHolder] (value
[org.apache.cxf.BusFactory$BusHolder@1998c335]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
{noformat}
> ThreadLoad org.apache.cxf.BusFactory.BusHolder leak in Tomcat
> -
>
> Key: CXF-5492
> URL: https://issues.apache.org/jira/browse/CXF-5492
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.7.6, 2.7.8, 2.7.14
> Environment: oracle jdk 7, windows7 x64
>Reporter: Alex O'Ree
>
> Upon web application redeploy (that calls a web service), I've been getting a
> number of log warnings when either Tomcat shutdown's down or when the web app
> is redeployed
> Jan 12, 2014 10:12:28 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: A web application created a ThreadLocal with key of type [null]
> (value [com.sun.xml.bind.v2.ClassFactory$1@fb0bc
> 0e]) and a value of type [java.util.WeakHashMap] (value [{class
> org.uddi.api_v3.BusinessList=java.lang.ref.WeakReference
> @1c0a432e, class
> org.uddi.api_v3.BusinessInfo=java.lang.ref.WeakReference@65c08f63, class
> org.uddi.api_v3.BusinessInfos=
> java.lang.ref.WeakReference@4505e0c5, class
> org.uddi.api_v3.Description=java.lang.ref.WeakReference@4e7c8ea, class org.u
> ddi.api_v3.Name=java.lang.ref.WeakReference@d377d2a, class
> org.uddi.api_v3.ServiceInfo=java.lang.ref.WeakReference@35fa5
> 72d, class java.util.ArrayList=java.lang.ref.WeakReference@4671670a, class
> javax.xml.bind.annotation.W3CDomHandler=java.
> lang.ref.WeakReference@3f23e5a7, class
> org.uddi.api_v3.ListDescription=java.lang.ref.WeakReference@4dba5753, class
> org.u
> ddi.api_v3.ServiceInfos=java.lang.ref.WeakReference@4bb3203}]) but failed to
> remove it when the web application was stop
> ped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
> Jan 12, 2014 10:12:28 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: A web application created a ThreadLocal with key of type
> [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1
> dd06562]) and a value of type [org.apache.cxf.BusFactory.BusHolder] (value
> [org.apache.cxf.BusFactory$BusHolder@5cb01438
> ]) bu
[jira] [Commented] (CXF-7231) Java HttpUrlConnection Reflection Fix to support custom verbs does not work with HTTPS
[
https://issues.apache.org/jira/browse/CXF-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839512#comment-15839512
]
Andrei Ivanov commented on CXF-7231:
Is the {{t.printStackTrace()}} intentional?
> Java HttpUrlConnection Reflection Fix to support custom verbs does not work
> with HTTPS
> --
>
> Key: CXF-7231
> URL: https://issues.apache.org/jira/browse/CXF-7231
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.9
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.10
>
>
> Java HTTPUrlConnection does not support custom HTTP verbs however CXF does
> the best effort at getting such methods supported by reflectively updating
> HTTPUrlConnection during the request.
> It does work with plain HTTP but still fails if HTTPS is used.
> More reflection fixes are needed.
> Note CXF does support such methods OOB with the Apache HttpClient based
> conduit which can be run in the async or sync modes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7232) Soap Async is incompatible with AutoRedirect=true
Benoit Wiart created CXF-7232: - Summary: Soap Async is incompatible with AutoRedirect=true Key: CXF-7232 URL: https://issues.apache.org/jira/browse/CXF-7232 Project: CXF Issue Type: Bug Components: JAX-WS Runtime, Transports Affects Versions: 3.1.9 Environment: java 8 Reporter: Benoit Wiart When using AutoRedirect=true with cxf-rt-transports-http-hc the call is correctly executed asynchronously through httpasyncclient BUT the original thread blocks until the end of the asynchronous execution. Switching AutoRedirect to false make the same call fully asynchronous. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7232) Soap Async is incompatible with AutoRedirect=true
[ https://issues.apache.org/jira/browse/CXF-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839779#comment-15839779 ] Benoit Wiart commented on CXF-7232: --- Stack trace of the blocked thread State: WAITING on org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream@7e21dc8f Total blocked: 1 Total waited: 3 Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:502) org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream.getHttpResponse(AsyncHTTPConduit.java:621) org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream.readHeaders(AsyncHTTPConduit.java:735) org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream.updateCookiesBeforeRetransmit(AsyncHTTPConduit.java:795) org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRetransmits(HTTPConduit.java:1410) org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1546) org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348) org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream.close(AsyncHTTPConduit.java:415) org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56) org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:216) org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651) org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) - locked org.apache.cxf.phase.PhaseInterceptorChain@49f6a9c0 org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:416) org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:394) org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:298) org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137) > Soap Async is incompatible with AutoRedirect=true > - > > Key: CXF-7232 > URL: https://issues.apache.org/jira/browse/CXF-7232 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, Transports >Affects Versions: 3.1.9 > Environment: java 8 >Reporter: Benoit Wiart > > When using AutoRedirect=true with cxf-rt-transports-http-hc the call is > correctly executed asynchronously through httpasyncclient BUT the original > thread blocks until the end of the asynchronous execution. > Switching AutoRedirect to false make the same call fully asynchronous. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7232) Soap Async is incompatible with AutoRedirect=true
[ https://issues.apache.org/jira/browse/CXF-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Wiart updated CXF-7232: -- Description: When using AutoRedirect=true with cxf-rt-transports-http-hc the call is correctly executed asynchronously through httpasyncclient BUT the original thread blocks until the end of the asynchronous execution. Switching AutoRedirect to false make the same call fully asynchronous by avoiding work in org.apache.cxf.transport.http.HTTPConduit.WrappedOutputStream.handleRetransmits() was: When using AutoRedirect=true with cxf-rt-transports-http-hc the call is correctly executed asynchronously through httpasyncclient BUT the original thread blocks until the end of the asynchronous execution. Switching AutoRedirect to false make the same call fully asynchronous. > Soap Async is incompatible with AutoRedirect=true > - > > Key: CXF-7232 > URL: https://issues.apache.org/jira/browse/CXF-7232 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, Transports >Affects Versions: 3.1.9 > Environment: java 8 >Reporter: Benoit Wiart > > When using AutoRedirect=true with cxf-rt-transports-http-hc the call is > correctly executed asynchronously through httpasyncclient BUT the original > thread blocks until the end of the asynchronous execution. > Switching AutoRedirect to false make the same call fully asynchronous by > avoiding work in > org.apache.cxf.transport.http.HTTPConduit.WrappedOutputStream.handleRetransmits() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7232) Soap Async is incompatible with AutoRedirect=true
[ https://issues.apache.org/jira/browse/CXF-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839789#comment-15839789 ] Benoit Wiart commented on CXF-7232: --- Looks like this bug can be triggered by other options like having MaxRetransmits > 0 (I did not try) > Soap Async is incompatible with AutoRedirect=true > - > > Key: CXF-7232 > URL: https://issues.apache.org/jira/browse/CXF-7232 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, Transports >Affects Versions: 3.1.9 > Environment: java 8 >Reporter: Benoit Wiart > > When using AutoRedirect=true with cxf-rt-transports-http-hc the call is > correctly executed asynchronously through httpasyncclient BUT the original > thread blocks until the end of the asynchronous execution. > Switching AutoRedirect to false make the same call fully asynchronous by > avoiding work in > org.apache.cxf.transport.http.HTTPConduit.WrappedOutputStream.handleRetransmits() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7228) ProviderInfo rarely supports proxies
[ https://issues.apache.org/jira/browse/CXF-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840012#comment-15840012 ] Sergey Beryozkin commented on CXF-7228: --- Romain, we are releasing most likely tomorrow, so I updated the code you referred to. I'm not sure the code in ServerProviderFactory is unsafe, it is only the assignment check, but I've updated it just in case too. I'll resolve this issue for 3.1.10, please open new issues if you discover the related problems in some other parts of the code, thanks > ProviderInfo rarely supports proxies > > > Key: CXF-7228 > URL: https://issues.apache.org/jira/browse/CXF-7228 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau > > CXF has a lot of pi.getProvider().getClass() usages but it breaks when using > proxies not propagating annotations (@Priority - > org.apache.cxf.jaxrs.provider.ServerProviderFactory.ServerConfigurationImpl#getPriority, > name bindings > org.apache.cxf.jaxrs.provider.ProviderFactory#getFilterNameBindings, etc) > Using at least org.apache.cxf.common.util.ClassHelper would solve this (and > this API is designed for it isnt it?). Also using ClassUnwrapper would be > consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7233) Create workaround for JDK HostnameVerifier issue
Colm O hEigeartaigh created CXF-7233: Summary: Create workaround for JDK HostnameVerifier issue Key: CXF-7233 URL: https://issues.apache.org/jira/browse/CXF-7233 Project: CXF Issue Type: Improvement Affects Versions: 3.0.12, 3.1.9 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.2.0, 3.1.10, 3.0.13 There is a bug in the JDK (> 8u65) that will be fixed in 8u152. There is a TLS handshake failure when a default HostnameVerifier is specified. There is a trivial workaround though to mitigate this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7213) FIQL Parser: Crashes when parsing a collection (java.util.Set) inside an object
[ https://issues.apache.org/jira/browse/CXF-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7213. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.0.13 3.1.10 3.2.0 Thanks for the tests and the proposed fix > FIQL Parser: Crashes when parsing a collection (java.util.Set) inside an > object > --- > > Key: CXF-7213 > URL: https://issues.apache.org/jira/browse/CXF-7213 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.5, 3.1.9 >Reporter: Hector Kikuchi Martins >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.10, 3.0.13 > > Attachments: CxfTest.java > > > The problem occur when an java.util.Set inside an object (not another > collection) is parsed. > Ex: "furniture.spec.features.description==description". > Furniture is a Set on an Room class. > Spec is an single Object on Furniture class. > Features is a Set on Spec class. > Description is a String on Feature class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7228) ProviderInfo rarely supports proxies
[ https://issues.apache.org/jira/browse/CXF-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7228. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.1.10 3.2.0 As I said, if you spot something else, ping me please :-) > ProviderInfo rarely supports proxies > > > Key: CXF-7228 > URL: https://issues.apache.org/jira/browse/CXF-7228 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.10 > > > CXF has a lot of pi.getProvider().getClass() usages but it breaks when using > proxies not propagating annotations (@Priority - > org.apache.cxf.jaxrs.provider.ServerProviderFactory.ServerConfigurationImpl#getPriority, > name bindings > org.apache.cxf.jaxrs.provider.ProviderFactory#getFilterNameBindings, etc) > Using at least org.apache.cxf.common.util.ClassHelper would solve this (and > this API is designed for it isnt it?). Also using ClassUnwrapper would be > consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7185) Xml validation with Mtom enabled is not working with french locale
[
https://issues.apache.org/jira/browse/CXF-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840165#comment-15840165
]
ASF GitHub Bot commented on CXF-7185:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/219
> Xml validation with Mtom enabled is not working with french locale
> --
>
> Key: CXF-7185
> URL: https://issues.apache.org/jira/browse/CXF-7185
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.7.18, 3.1.9
>Reporter: Kevin Buntrock
>
> Running cxf on a tomcat launched with the jvm argument "-Duser.language=fr".
> Mtom and schema validation are enabled.
> While sending a soap message, we have this error : "Wrapped by:
> org.apache.camel.RuntimeCamelException: org.apache.cxf.interceptor.Fault:
> Marshalling Error: cvc-type.3.1.2 : L'élément 'xxx' est de type simple et ne
> doit comporter aucun enfant ([children]) de type élément d'information."
> Reason is a lack in the hack allowing validation with mtom enabled in
> org.apache.cxf.jaxb.io.DataWriterImpl.java.
> {code:java}
> private static class MtomValidationHandler implements ValidationEventHandler {
> ValidationEventHandler origHandler;
> JAXBAttachmentMarshaller marshaller;
> public MtomValidationHandler(ValidationEventHandler v,
>JAXBAttachmentMarshaller m) {
> origHandler = v;
> marshaller = m;
> }
> public boolean handleEvent(ValidationEvent event) {
> // CXF-1194 this hack is specific to MTOM, so pretty safe to leave
> in here before calling the origHandler.
> String msg = event.getMessage();
> if (msg.startsWith("cvc-type.3.1.2: ")
> &&
> msg.contains(marshaller.getLastMTOMElementName().getLocalPart())) {
> return true;
> }
>
> if (origHandler != null) {
> return origHandler.handleEvent(event);
> }
> return false;
> }
> }
> {code}
>
> In french, the colon is always separated with a space from the preceding word
> : "cvc-type.3.1.2 : "
> I would reckon to just not include the colon anymore in the checking. It
> seams useless according to this documentation :
> https://wiki.xmldation.com/Support/Validator
> Looking quickly on the code, some other hacks should not work in french in
> the sibling class DataReaderImpl.java.
> I will submit a pull request during the week-end to correct this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7185) Xml validation with Mtom enabled is not working with french locale
[
https://issues.apache.org/jira/browse/CXF-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7185.
--
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.1.10
> Xml validation with Mtom enabled is not working with french locale
> --
>
> Key: CXF-7185
> URL: https://issues.apache.org/jira/browse/CXF-7185
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.7.18, 3.1.9
>Reporter: Kevin Buntrock
>Assignee: Daniel Kulp
> Fix For: 3.1.10
>
>
> Running cxf on a tomcat launched with the jvm argument "-Duser.language=fr".
> Mtom and schema validation are enabled.
> While sending a soap message, we have this error : "Wrapped by:
> org.apache.camel.RuntimeCamelException: org.apache.cxf.interceptor.Fault:
> Marshalling Error: cvc-type.3.1.2 : L'élément 'xxx' est de type simple et ne
> doit comporter aucun enfant ([children]) de type élément d'information."
> Reason is a lack in the hack allowing validation with mtom enabled in
> org.apache.cxf.jaxb.io.DataWriterImpl.java.
> {code:java}
> private static class MtomValidationHandler implements ValidationEventHandler {
> ValidationEventHandler origHandler;
> JAXBAttachmentMarshaller marshaller;
> public MtomValidationHandler(ValidationEventHandler v,
>JAXBAttachmentMarshaller m) {
> origHandler = v;
> marshaller = m;
> }
> public boolean handleEvent(ValidationEvent event) {
> // CXF-1194 this hack is specific to MTOM, so pretty safe to leave
> in here before calling the origHandler.
> String msg = event.getMessage();
> if (msg.startsWith("cvc-type.3.1.2: ")
> &&
> msg.contains(marshaller.getLastMTOMElementName().getLocalPart())) {
> return true;
> }
>
> if (origHandler != null) {
> return origHandler.handleEvent(event);
> }
> return false;
> }
> }
> {code}
>
> In french, the colon is always separated with a space from the preceding word
> : "cvc-type.3.1.2 : "
> I would reckon to just not include the colon anymore in the checking. It
> seams useless according to this documentation :
> https://wiki.xmldation.com/Support/Validator
> Looking quickly on the code, some other hacks should not work in french in
> the sibling class DataReaderImpl.java.
> I will submit a pull request during the week-end to correct this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7233) Create workaround for JDK HostnameVerifier issue
[ https://issues.apache.org/jira/browse/CXF-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7233. -- Resolution: Fixed > Create workaround for JDK HostnameVerifier issue > > > Key: CXF-7233 > URL: https://issues.apache.org/jira/browse/CXF-7233 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.9, 3.0.12 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 3.2.0, 3.1.10, 3.0.13 > > > There is a bug in the JDK (> 8u65) that will be fixed in 8u152. There is a > TLS handshake failure when a default HostnameVerifier is specified. There is > a trivial workaround though to mitigate this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7233) Create workaround for JDK HostnameVerifier issue
[ https://issues.apache.org/jira/browse/CXF-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7233: - Description: There is a bug in the JDK (> 8u65) that will be fixed in 8u152: https://bugs.openjdk.java.net/browse/JDK-8144566 There is a TLS handshake failure when a default HostnameVerifier is specified. There is a trivial workaround though to mitigate this issue. was:There is a bug in the JDK (> 8u65) that will be fixed in 8u152. There is a TLS handshake failure when a default HostnameVerifier is specified. There is a trivial workaround though to mitigate this issue. > Create workaround for JDK HostnameVerifier issue > > > Key: CXF-7233 > URL: https://issues.apache.org/jira/browse/CXF-7233 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.9, 3.0.12 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 3.2.0, 3.1.10, 3.0.13 > > > There is a bug in the JDK (> 8u65) that will be fixed in 8u152: > https://bugs.openjdk.java.net/browse/JDK-8144566 > There is a TLS handshake failure when a default HostnameVerifier is > specified. There is a trivial workaround though to mitigate this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
[ https://issues.apache.org/jira/browse/CXF-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-7229: -- Attachment: proxy-test-case.txt Hey Sergey, I am attaching a simple test case to illustrate how to reproduce the issue. It is a little bit ad-hoc, but the same result could be achieved using f.e. @Inject or @Autowired annotations, when the proxy is returned instead of real object. The test case is failing right now, the proxy object is not serialized into its proxied instance. Thanks. Best Regards, Andriy Redko > ClassHelper usages not replacable by ClassUnwrapper > --- > > Key: CXF-7229 > URL: https://issues.apache.org/jira/browse/CXF-7229 > Project: CXF > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Andriy Redko > Attachments: proxy-test-case.txt > > > ClassUnwrapper and ClassHelper are pretty close and for an app setting a > single one should be enough (in particular cause ClassHelper overriding is > hacky) > Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for > instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6962) Basic auth uses UTF-8 for the encoded password when it should use ISO-8859-1
[ https://issues.apache.org/jira/browse/CXF-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840502#comment-15840502 ] Sergey Beryozkin commented on CXF-6962: --- Hi, I agree it is a problem, the question is how to solve it now without breaking CXF clients which may be already encoding a character like "§" using UTF-8 which works against a CXF server decoding with UTF-8. May be we can try to come up with a property instructing CXF to use ISO-8859-1, too late for 3.1.10 but possible for 3.1.11 > Basic auth uses UTF-8 for the encoded password when it should use ISO-8859-1 > > > Key: CXF-6962 > URL: https://issues.apache.org/jira/browse/CXF-6962 > Project: CXF > Issue Type: Bug >Affects Versions: 2.7.18, 3.1.6 >Reporter: Chris Dolphy > > Basic auth uses UTF-8 for the encoded password when it should use ISO-8859-1. > Also (or instead), implement RFC 7617 which allows a server to indicate it > does support UTF-8. > The RFC that covers Basic authentication says that the authentication header > contains base 64 encoded TEXT [1]. The TEXT format needs to be read under > the HTTP specification [2] which says: >The TEXT rule is only used for descriptive field contents and values >that are not intended to be interpreted by the message parser. Words >of *TEXT MAY contain characters from character sets other than ISO- >8859-1 [22] only when encoded according to the rules of RFC 2047 >[14]. > RFC 2047 describes an encoding method that embeds the encoded string in "=?" > and "?=". But it appears no implementation of HTTP is doing this. Certainly > no browser is doing this. > [1] http://tools.ietf.org/html/rfc2617#section-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
