[jira] [Created] (CXF-7091) JAXRSBeanValidationOutInterceptor fails to validate Response entity on the 2nd try

[Sergey Beryozkin (JIRA)]

Sergey Beryozkin created CXF-7091:
-

 Summary: JAXRSBeanValidationOutInterceptor fails to validate 
Response entity on the 2nd try
 Key: CXF-7091
 URL: https://issues.apache.org/jira/browse/CXF-7091
 Project: CXF
  Issue Type: Bug
  Components: JAX-RS
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
 Fix For: 3.2.0, 3.1.9, 3.0.12


JAX-RS out filters can be run twice if the exception thrown from these filters 
during the 1st run has been mapped.  JAXRSBeanValidationOutInterceptor fails to 
pass the mapped Response to the abstract validation code. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted

[Grzegorz Maczuga (JIRA)]

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

Grzegorz Maczuga reopened CXF-7088:
---

Hi Colm,

Actually we turn off Encryption completely to see that sent request contains 
just extra UsernameToken.

In such case such request is processed by CXF - with SAML Assertion being only 
signed, not encrypted as required by WS-Policy. 

See file attached.

> SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being 
> accepted
> --
>
> Key: CXF-7088
> URL: https://issues.apache.org/jira/browse/CXF-7088
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Grzegorz Maczuga
>Assignee: Colm O hEigeartaigh
> Attachments: message_anonymous.txt, policy.txt
>
>
> In WS-Policy that is used by service we have defined 
> 
> Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion 
> that is inside WS-Security section of the message SOAP Header should be 
> encrypted (not only signed).
> Message with SAML that is NOT encrypted is currently accepted by CXF even 
> while policy defines 
> Question is: does SAML assertion fall into "SupportingTokens" category and 
> should be encrypted as well?
> What is your view on that? Is that a bug in Neethi?
> See 
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566
> Signed, encrypted supporting tokens are Signed supporting tokens (See section 
> 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. 
> Element Encryption SHOULD be used for encrypting the supporting tokens.
> The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax 
> of sp:SignedSupportingTokens only in the name of the assertion itself. All 
> nested policy is as per the sp:SignedSupportingTokens assertion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6938) Setting the providers on a bus causes a leak if this bus is used by per-request clients

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6938.


> Setting the providers on a bus causes a leak if this bus is used by 
> per-request clients
> ---
>
> Key: CXF-6938
> URL: https://issues.apache.org/jira/browse/CXF-6938
> Project: CXF
>  Issue Type: Task
>  Components: Bus, JAX-RS
>Affects Versions: 3.1.0, 3.1.6
> Environment: Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7
>Reporter: RANADEEP SHARMA
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> We have an application with REST client components for making calls to 
> Backend web services. During our routine performance test, JProfiler tool 
> shows lots of Bus property entries (with keys named 
> "bus.providers.set.") populated while creating instances of 
> ClientProviderFactory.
> These Bus property entries seem to stay in heap for the whole duration of the 
> 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap.
> In short, GC doesn't seem to happening frequently enough to keep the heap 
> usage within limits.
> Is this some sort of a bug or, lack of necessary configuration in CXF?
> Either ways, we need your guidance for trouble-shooting this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6853) Support encoded value in @ApplicationPath

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6853.


> Support encoded value in @ApplicationPath
> -
>
> Key: CXF-6853
> URL: https://issues.apache.org/jira/browse/CXF-6853
> Project: CXF
>  Issue Type: Task
>  Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> If @ApplicationPath value is  an encoded value, if client send request to 
> http://localhost:8080/Application!/myresource and get 404 .
> {code}
> @ApplicationPath("ApplicationPath%21")
> public class MyApp extends Application {
>   public java.util.Set getClasses() {
> Set resources = new HashSet();
> resources.add(MyResource.class);
> return resources;
> }   
> }
> {code}
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6927) check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6927.


> check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use 
> IBM JDK
> -
>
> Key: CXF-6927
> URL: https://issues.apache.org/jira/browse/CXF-6927
> Project: CXF
>  Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6901) UriBuilder may lose resolved query templates

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6901.


> UriBuilder may lose resolved query templates
> 
>
> Key: CXF-6901
> URL: https://issues.apache.org/jira/browse/CXF-6901
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Typically one would start resolving at the final build() time, however, with 
> resolveTemplate variations one can build step by step. In this case, if a 
> template is part of the query component then if the resolved template has 
> ended up in the list of the values which will need the extra encoding step, 
> then this resolved template value will be lost  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6943) Dead lock on Async Response when timeout is set

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6943.


> Dead lock on Async Response when timeout is set
> ---
>
> Key: CXF-6943
> URL: https://issues.apache.org/jira/browse/CXF-6943
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.4, 3.1.6
> Environment: The bug was detected on :
>   - Java 1.7.0_11
>   - Tomcat 8.0.23
>   - CXF 3.0.4
>   - Red Hat 6.5
> The bug is also available on :
>   - Java 1.8.0_77
>   - Tomcat 8.0.35
>   - CXF 3.1.6
>   - Red Hat 6.5
>Reporter: MOIRE Antony
>Assignee: Sergey Beryozkin
>  Labels: test
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: Main_Thread_error.txt, Working_Thread_error.txt, 
> async-response-test.zip
>
>
> Hello,
> When using AsyncResponse with timeout and an external thread for the 
> treatment, it seems that a dead lock appears between the main http thread and 
> the treatment thread when the treatment thread finished before the main 
> thread :
> Here is the code which reproduces this issue :
> public Response asyncResponseTestKo(HttpServletRequest request, final 
> AsyncResponse ar) {
> Response r = null;
> LOGGER.info("Get request asyncResponseTestKo");
> ar.setTimeout(10, TimeUnit.SECONDS);
> poolExecutor.execute(new Runnable() {
> @Override
> public void run() {
> ar.resume(Response.ok().build());
> }
> });
> try {
> Thread.sleep(2000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> return r;
> }
> The main thread error is :
> 2016-06-15 14:47:44
> "http-nio-9080-exec-1" - Thread t@25
>java.lang.Thread.State: BLOCKED
>   at 
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl.suspendContinuationIfNeeded(AsyncResponseImpl.java:263)
>   - waiting to lock <792a9e17> (a 
> org.apache.cxf.jaxrs.impl.AsyncResponseImpl) owned by "pool-1-thread-1" t@26
>   at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:191)
>   at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>   - locked <5f36a728> (a org.apache.cxf.phase.PhaseInterceptorChain)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>   at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>   at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
>   at 
> 

[jira] [Closed] (CXF-6935) Better error message than java.lang.NullPointerException - org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:187) when running on a JRE instead of JDK

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6935.


> Better error message than java.lang.NullPointerException - 
> org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:187) when 
> running on a JRE instead of JDK
> ---
>
> Key: CXF-6935
> URL: https://issues.apache.org/jira/browse/CXF-6935
> Project: CXF
>  Issue Type: Improvement
>Affects Versions: 3.1.6
> Environment: java version "1.7.0_79"
> Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
>Reporter: Gary Gregory
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: cxf.patch
>
>
> CXF needs a better error message than {{java.lang.NullPointerException - 
> org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:187)}} 
> when running on a JRE instead of JDK.
> {noformat}
> 2016-06-06 10:47:09,902 [qtp16583278-30] ERROR: 
> java.lang.NullPointerException - 
> org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:187)
> java.lang.NullPointerException
> at 
> org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:187)
> at 
> org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at 
> org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:136)
> at 
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.compileJavaSrc(DynamicClientFactory.java:611)
> at 
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:370)
> at 
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:276)
> at 
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:269)
> at 
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:204)
> {noformat}
> The method {{javax.tools.ToolProvider.getSystemJavaCompiler()}} is documented 
> to return {{null}} if no compiler is provided.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6917) SuperClass and Interface's Annotations are ignored when the Method contains ParameterAnnotation

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6917.


> SuperClass and Interface's Annotations are ignored when the Method contains 
> ParameterAnnotation
> ---
>
> Key: CXF-6917
> URL: https://issues.apache.org/jira/browse/CXF-6917
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.6
> Environment: Mac java 8
>Reporter: Neal Hu
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.2.0, 3.1.8
>
>
> Suppose we have below interface and its implementation:
> public interface HelloWorld {
> @GET
> @Path("/hello")
> String sayHello(@QueryParam("name") String name);
> @GET
> @Path("/hello3")
> String sayHello3();
> }
> @Path("/")
> public class HelloWorldImpl implements HelloWorld {
>   @Override
>   public String sayHello(@QueryParam("name") String name){
>   return "hello " + name;
>   }
>   @GET
>   @Path("/hello2")
>   public String sayHello2(@QueryParam("name") String name){
>   return "hello2 " + name;
>   }
>   @Override
>   public String sayHello3(){
>   return "hello3 ";
>   }
> }
> Get /hello3 works good. but Get /hello?name=neal will result in 404. The 
> expected output is hello neal.
> The root cause is in org.apache.cxf.jaxrs.utils.AnnotationUtils:167 CXF 
> ignores the recurrence search of the method who has parameter annotations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6910.


> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level 
> timeout, that said, if there's no data on the socket in a certain time, the 
> connection would be closed, this overrule the TTL value of a connection, 
> which means the connection timeToLive can't be managed by a 
> connectionPoolManager, this is really painful for heavy loaded client request 
> as we want the connectionPoolManager to manage the connection so that we 
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set 
> that at socket level, so that let the connectionPoolManager can decide the 
> connection TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6729.


>  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
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7
>
> 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] [Closed] (CXF-6971) Update Jettison version to 1.3.8

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6971.


> Update Jettison version to 1.3.8
> 
>
> Key: CXF-6971
> URL: https://issues.apache.org/jira/browse/CXF-6971
> Project: CXF
>  Issue Type: Task
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6878) Protect against other exception during consuming left-over data

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6878.


> Protect against other exception during consuming left-over data
> ---
>
> Key: CXF-6878
> URL: https://issues.apache.org/jira/browse/CXF-6878
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.1.5, 3.0.9
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Make the processing of the fault response serialization more robust so that 
> an exception thrown during the cleanup of the left-over input stream will not 
> abort the fault response serialization processing. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6912) introduce CONNECTION_MAX_IDLE property for AHC

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6912.


> introduce CONNECTION_MAX_IDLE property for AHC
> --
>
> Key: CXF-6912
> URL: https://issues.apache.org/jira/browse/CXF-6912
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently we have the CONNECTION_TTL property for AHC, this is used to 
> specify a connection TimeToLive, no matter the connection is active or not. 
> For some scenarios, users wanna specify the value for how long an idle 
> connection should exist in the connection pool, if reach that timespan, just 
> close the idle connection.
> We need introduce another property named CONNECTION_MAX_IDLE to do it. To let 
> CONNECTION_MAX_IDLE take effect, customer need configure CONNECTION_TTL as 
> "0" which means the connection does not have an expiry deadline and use the 
> CONNECTION_MAX_IDLE to close the idle connection only, so that the actively 
> used connection could be still reused by the connection pool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6586) Missing some bean properties in Swagger2Feature

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6586.


> Missing some bean properties in Swagger2Feature
> ---
>
> Key: CXF-6586
> URL: https://issues.apache.org/jira/browse/CXF-6586
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.0.6, 3.1.2
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.3, 3.0.7
>
>
> adding the following missing properties
> - schemes
> - filterClass
> - termsOfServiceUrl
> - prettyPrint



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6550) AsyncConduitHTTPFactory will throw NPE if passed properties are null

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6550.


> AsyncConduitHTTPFactory will throw NPE if passed properties are null 
> -
>
> Key: CXF-6550
> URL: https://issues.apache.org/jira/browse/CXF-6550
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.1.3, 3.0.7
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6601) Swagger2Feature can hit a NPE when running in localtransport

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6601.


> Swagger2Feature can hit a NPE when running in localtransport
> 
>
> Key: CXF-6601
> URL: https://issues.apache.org/jira/browse/CXF-6601
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.3
>Reporter: David J. M. Karlsen
>Assignee: Akitoshi Yoshida
> Fix For: 3.0.7, 3.1.4
>
>
> mc.getServletContext() can be null when running with localTransport



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6660) SamlTokenInterceptor Jasypt decryption

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6660.


> SamlTokenInterceptor Jasypt decryption
> --
>
> Key: CXF-6660
> URL: https://issues.apache.org/jira/browse/CXF-6660
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 3.1.3
> Environment: cxf 3.1.2, wss4j 2.1.2, spring boot 1.2.6
>Reporter: Ethan Ma
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.1.5, 3.0.8
>
>
> This is happening when using SamlTokenInterceptor to validate the inbound 
> saml token via WS-SecurityPolicy.
> It seems that the crypto get back from SamlTokenInterceptor is always having 
> null PasswordEncryptor. The keystore password is not therefore decrypted 
> properly.
> SamlTokenInterceptor.java line 320:
> crypto = CryptoFactory.getInstance(properties);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6712) [cxf-java2wadl-plugin] Add parameter encoding to goal parsejavadoc

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6712.


> [cxf-java2wadl-plugin] Add parameter encoding to goal parsejavadoc
> --
>
> Key: CXF-6712
> URL: https://issues.apache.org/jira/browse/CXF-6712
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.4
>Reporter: dur
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> The cxf-java2wadl-plugin uses always the platform encoding
> {code}
> [warn] Source files encoding has not been set, using platform encoding 
> Cp1252, i.e. build is platform dependent!
> {code}
> which produces errors, if source has another encoding. 
> The used maven-javadoc-plugin has a parameter for encoding, it should be set 
> in ParseJavaDocMojo.
> Something like:
> {code}
> @Parameter( property = "encoding", defaultValue = 
> "${project.build.sourceEncoding}" )
> private String encoding;
> @Override
> public void execute() throws MojoExecutionException, MojoFailureException {
> AbstractJavadocMojo mojo = new JavadocReport();
> Locale locale = Locale.getDefault();
> try {
> Field f = AbstractJavadocMojo.class.getDeclaredField("encoding");
> f.setAccessible(true);
> f.set(mojo, encoding);
> {code}
> should do it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6595) CXF Karaf feature file: set dependency = true in the jta bundle for CXF

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6595.


> CXF Karaf feature file: set dependency = true in the jta bundle for CXF
> ---
>
> Key: CXF-6595
> URL: https://issues.apache.org/jira/browse/CXF-6595
> Project: CXF
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: 3.1.2
> Environment: Karaf 4.0.1
>Reporter: Jochen Walz
>Assignee: Christian Schneider
> Fix For: 3.1.4
>
>
> Currently, geronimo-jta_1.1_spec is installed in any case when installing the 
> CXF feature in Karaf. This causes a conflict if another version of the 
> transaction api (1.2.0) has already been installed, e.g. with the Karaf 
> eclipselink feature.
> Adding some more details from mailing list:
> When installing the new eclipselink feature (version 2.6.0) together with CXF
> 3.1.2, there seems to be a conflict with two versions of the
> transaction-api: eclipselink brings version 1.2.0 with
> javax.transaction-api, CXF brings 1.1.0 with geronimo-jta_1.1_spec. When
> both are installed, Aries Transaction Blueprint doesn't get the
> javax.transaction.TransactionManager objectClass, and therefore doesn't
> provide the transaction namespace.
> When I remove geronimo-jta_1.1_spec from the cxf-transports-jms of CXF,
> Aries Transaction Blueprint works. I haven't checked whether CXF functions
> are still available, but at least all bundles are activated. And a
> persistence unit at least reaches the failure point described  here
> 
>   
> (by the way: I would also be interested in a solution for that one).
> My question: is there a better way to reach this? Or would this a Jira for
> CXF to update the cxf-transports-jms feature to use the newer transaction
> API?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-5118) Create CXF interceptor which will use HTTPS client certificates to create JAAS SecurityContext

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-5118.


> Create CXF interceptor which will use HTTPS client certificates to create 
> JAAS SecurityContext 
> ---
>
> Key: CXF-5118
> URL: https://issues.apache.org/jira/browse/CXF-5118
> Project: CXF
>  Issue Type: New Feature
>  Components: Core
>Reporter: Sergey Beryozkin
>Assignee: Christian Schneider
> Fix For: 3.1.4
>
>
> Use case:
> The user authenticates against the webservice using an X509 client 
> certificate. In case of successful authentication the JAAS security context 
> should be populated with a Subject that stores the user name and the roles of 
> the user. This is necessary to support Authorization at a later stage.
> Design ideas
> The SSL transport will be configured to only accept certain client 
> certificates. So we can assume that the interceptor does not have to do a 
> real authentication. Instead it has to map from the subjectDN of the 
> certificate to the user name and then lookup the roles of that user. Both 
> then has to be stored in the subject's principles.
> The mapping could be done inside a JAASLoginModule or before. Inside will 
> give the user more flexibility.
> The next step to retrieve the roles should be done in one of the standard 
> JAASLoginModules as the source of the roles can be quite diverse. So for 
> example the LdapLoginModule allows to retrieve the roles from Ldap. At the 
> moment these modules require the password of the user though which is not 
> available when doing a cert based auth.
> So I see two variants to retrieve the roles:
> 1. Change the loginmodules like the LDAP one to be configureable to use a 
> fixed ldap user for the ldap connect and not require the user password. So 
> the module would have two modes: a) normal authentication and group gathering 
> b) use a fixed user to just retrieve roles for a given user
> 2. Store the user password somewhere (e.g. in the mapping file). In this case 
> the existing LDAPLoginModule could be used but the user password would be 
> openly in a text file
> 3. Create new LoginModules with the desired behaviour (fixed user and only 
> lookup of roles)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6630) Cannot call setAttribute with a null name

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6630.


> Cannot call setAttribute with a null name
> -
>
> Key: CXF-6630
> URL: https://issues.apache.org/jira/browse/CXF-6630
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.2, 3.1.3
>Reporter: Jan Vondrouš
>Assignee: Sergey Beryozkin
> Fix For: 3.0.7, 3.1.4
>
>
> After update on version 3.1.2. Our application ends with this Exception
> ...
> Caused by: java.lang.IllegalArgumentException: Cannot call setAttribute with 
> a null name
>   at org.apache.catalina.connector.Request.setAttribute(Request.java:1500)
>   at 
> org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:541)
>   at 
> javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:239)
>   at 
> javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:239)
>   at 
> org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.writeTo(RequestDispatcherProvider.java:212)
>   ... 59 more
> I believe, that i know where is problem and that fix is really trivial:
> Class:
> org.apache.cxf.jaxrs.provider.RequestDispatcherProvider
> have method
> protected String getBeanName(Object bean) {
> ...
> String name = beanNames.get(bean.getClass().getName());
> if (name != null) {
> return null;
> } 
> ...
> }
> This return null and cause exception (stacktrace is above)
> Fix should be trivial just change "return null;"
> into
> "return name;"
> I believe, that it is correct fix, because code in version 3.1.1 looked like 
> this:
> String name = beanNames.get(bean.getClass().getName());
> return name != null ? name : 
> bean.getClass().getSimpleName().toLowerCase();
> Thanks for fix, because we want use new version of CXF. And we cannot due to 
> this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6658) Make ServletContextResourceResolver optionally ignored

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6658.


> Make ServletContextResourceResolver optionally ignored 
> ---
>
> Key: CXF-6658
> URL: https://issues.apache.org/jira/browse/CXF-6658
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.7.18, 3.0.7, 3.1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6643) Upgrade Apache HTrace to 4.0

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6643.


> Upgrade Apache HTrace to 4.0 
> -
>
> Key: CXF-6643
> URL: https://issues.apache.org/jira/browse/CXF-6643
> Project: CXF
>  Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
> Fix For: 3.1.4
>
>
> Apache HTrace to 4.0 has been released recently with very different API 
> comparing to 3.x release branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6527) WSDLRefValidator reject valid target reference URI/IRI

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6527.


> WSDLRefValidator reject valid target reference URI/IRI
> --
>
> Key: CXF-6527
> URL: https://issues.apache.org/jira/browse/CXF-6527
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Reporter: Romain Chantereau
>Assignee: Akitoshi Yoshida
>Priority: Minor
> Fix For: 3.1.3, 2.7.18, 3.0.7
>
>
> When a target namespace have “:” in the path part of the URI, the validator 
> reject the WSDL.
> This is due to this piece of code at line 137 of 
> {{tools/validator/src/main/java/org/apache/cxf/tools/validator/internal/WSDLRefValidator.java}}
>  file.
> {code:java}
> private void checkTargetNamespace(String path) {
>  try {
> if (new URL(path).getPath().indexOf(":") != -1) {
> throw new ToolException(": is not a valid char in the 
> targetNamespace");
> }
>} catch (MalformedURLException e) {
> // do nothing
>}
> }
> {code}
> I checked the following specifications:
> * [XML namespace|http://www.w3.org/TR/xml-names/]
> * [URI|http://www.rfc-editor.org/rfc/rfc3986.txt]
> * [IRI|http://www.ietf.org/rfc/rfc3987.txt]
> * [WSDL 2.0 Target 
> namespace|http://www.w3.org/TR/wsdl20/#Description_targetnamespace_attribute]
> * [WSDL service definition|http://www.w3.org/TR/wsdl#_service]
> and nothing forbids having a target namespace like the following one:
> {{http://host:port/part/part/resource:resource}}
> Then the validator add an extra constraint on the WSDL format without any 
> explanation.
> I looked into the source history, this validation is here since a long period 
> (before going to git), then I was not able to find out the reason behind this 
> explicit check.
> Could fix this bug or explain why there is a such limitation?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6606) Encoded characters in URI are decoded multiple times during preprocess

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6606.


> Encoded characters in URI are decoded multiple times during preprocess
> --
>
> Key: CXF-6606
> URL: https://issues.apache.org/jira/browse/CXF-6606
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.2
>Reporter: Tyler Brazier
>Assignee: Sergey Beryozkin
> Fix For: 3.1.3, 2.7.18, 3.0.7
>
>
> When given a url like {{/api/%255E/users.json}}, 
> {{RequestPreprocessor#preprocess}} first does {{handleExtensionMappings}}, 
> which creates a {{PathSegmentImpl}} with a single arg constructor, decoding 
> the path. The path on {{Message}} is set to the decoded path with a call to 
> {{updatePath}} if the {{.json}} extension was found within the extension 
> mappings. Back in {{RequestPreprocessor#preprocess}}, the path returned will 
> be decoded again within the call to {{UriInfoImpl#getPath}}.
> This causes the {{%255E}} in the path to be decoded the first time as 
> {{%5E}}, then the second time as {{^}}.
> I believe this could be fixed by constructing {{PathSegment}} within 
> {{handleLanguageMappings}} and {{handleExtensionMappings}} with a second 
> {{false}} argument.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6793) InvocationCallback doesn't try to get response class type

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6793.


> InvocationCallback doesn't try to get response class type
> -
>
> Key: CXF-6793
> URL: https://issues.apache.org/jira/browse/CXF-6793
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.5
>Reporter: Romain Manni-Bucau
>Assignee: Sergey Beryozkin
> Fix For: 3.1.6, 3.0.9, 3.2.0
>
>
> in org.apache.cxf.jaxrs.client.WebClient#doInvokeAsyncCallback the webclient 
> could try to find the response class if not there.
> would avoid to give a null type the providers can't use to do what they need 
> to
> Code can be if respClass is null and callback is not null something like:
> {code}
> // in real code filter interfaces and dont access them directly by index
> ParameterizedType.class.cast(callback.getClass().getGenericInterfaces()[0]).getActualTypeArguments()[0]
> {code}
> edit: digging a bit seems 
> org.apache.cxf.jaxrs.utils.InjectionUtils#getSuperType just doesn't default 
> to anything and in case of TypeVariable unbounded is not able to default to 
> Object so if bound is really Object it fails
> if it helps here is the code I use: 
> https://gist.github.com/rmannibucau/09a084c28d8b61c232cf - of course would 
> like to make the class geenric () and remove this String typing ;)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6764) Should add RI JAXB Namespacemapper support

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6764.


> Should add RI JAXB Namespacemapper support
> --
>
> Key: CXF-6764
> URL: https://issues.apache.org/jira/browse/CXF-6764
> Project: CXF
>  Issue Type: Bug
>  Components: Core, JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
>Assignee: Daniel Kulp
> Fix For: 3.1.6, 3.0.9
>
>
> /cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
> {code:java}
> if (cls == null
> && (mcls.getName().contains(".internal.") || 
> mcls.getName().contains("com.sun"))) {
> try {
> cls = 
> ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper", 
>  JAXBUtils.class);
> } catch (ClassNotFoundException ex2) {
> // ignore
> }
> }
> {code}
> CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends 
> com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a 
> mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
> So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB 
> cann't add the namespace mapping correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6568) Default WebApplicationExceptionMapper should be optionally made less specific

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6568.


> Default WebApplicationExceptionMapper should be optionally made less specific
> -
>
> Key: CXF-6568
> URL: https://issues.apache.org/jira/browse/CXF-6568
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.3, 3.0.7
>
>
> Now that the default and custom providers are kept in a single 
> ProviderFactory with a parent-child relationship the default 
> WebApplicationExceptionMapper will win over custom providers which are less 
> specific (ex, RuntimeException mappers) but which expect to catch 
> WebApplicationException.
> It is been confirmed on the spec experts list that it is expected that custom 
> mappers can catch WAE thrown by the runtime itself therefore the fact that 
> CXF uses WAE to enforce spec-related error conditions is sound.
> There's no clarity though how the runtime is expected to manages such 
> runtime-originated WAEs - via its own WAE mapper or even RuntimeException 
> mapper or somehow else.
> Therefore a property "make.default.wae.least.specific" is introduced to 
> ensure a CXF default WAE mapper is only used if no other custom mapper can 
> handle a given WAE to minimize any portability concerns.
> This can be further addressed once we get more clarity on the issue   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6813) MediaTypeHeaderProvider doesn't check the illegal media type string like "s//tt;type=text/plain"

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6813.


> MediaTypeHeaderProvider doesn't check the illegal media type string like 
> "s//tt;type=text/plain"
> 
>
> Key: CXF-6813
> URL: https://issues.apache.org/jira/browse/CXF-6813
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.1.6, 3.2.0
>
>
> Call MediaType.valueOf("s//t;type=a/b") ,  IllegalArgumentException is 
> expected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575483#comment-15575483
 ] 

Colm O hEigeartaigh commented on CXF-7088:
--

Is the message received over TLS by any chance? If so this counts as 
"encrypted".

Colm.

> SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being 
> accepted
> --
>
> Key: CXF-7088
> URL: https://issues.apache.org/jira/browse/CXF-7088
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Grzegorz Maczuga
>Assignee: Colm O hEigeartaigh
> Attachments: messageNoEncryption.txt, message_anonymous.txt, 
> policy.txt
>
>
> In WS-Policy that is used by service we have defined 
> 
> Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion 
> that is inside WS-Security section of the message SOAP Header should be 
> encrypted (not only signed).
> Message with SAML that is NOT encrypted is currently accepted by CXF even 
> while policy defines 
> Question is: does SAML assertion fall into "SupportingTokens" category and 
> should be encrypted as well?
> What is your view on that? Is that a bug in Neethi?
> See 
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566
> Signed, encrypted supporting tokens are Signed supporting tokens (See section 
> 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. 
> Element Encryption SHOULD be used for encrypting the supporting tokens.
> The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax 
> of sp:SignedSupportingTokens only in the name of the assertion itself. All 
> nested policy is as per the sp:SignedSupportingTokens assertion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6771) JAX-RS ContextProvider should be able to support Servlet contexts

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6771.


> JAX-RS ContextProvider should be able to support Servlet contexts
> -
>
> Key: CXF-6771
> URL: https://issues.apache.org/jira/browse/CXF-6771
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.6, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6820) LinkBuilderImpl#link() doesn't throw exception for invalid input

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6820.


> LinkBuilderImpl#link() doesn't throw exception for invalid input
> 
>
> Key: CXF-6820
> URL: https://issues.apache.org/jira/browse/CXF-6820
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.1.6, 3.2.0
>
>
> It should throw exception for the invalid input like : 
> linkBuilder.link(">");



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6808) Update JWS/JWE utils to load named properties

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6808.


> Update JWS/JWE utils to load named properties
> -
>
> Key: CXF-6808
> URL: https://issues.apache.org/jira/browse/CXF-6808
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.6, 3.2.0
>
>
> Right now JOSE utils load JWE/JWS properties identified by CXF message 
> contextual properties such as RSSES_SIGNATURE(IN/OUT)_PROPS, etc.
> In a complex system such as OIDC/etc it can become limiting, for example, the 
> same endpoint may need to use different output/input signature/encryption 
> tasks so with using a single properties file it may be difficult to identify 
> which algorithm applies to which operation, etc...
> Supporting loading named properties files will make it easier, with the 
> system knowing in advance which properties file is needed for which operation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6435) Support base64 for attachment encoding in CXF

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6435.


> Support base64 for attachment encoding in CXF
> -
>
> Key: CXF-6435
> URL: https://issues.apache.org/jira/browse/CXF-6435
> Project: CXF
>  Issue Type: Bug
>Reporter: Susan Javurek
>Assignee: Freeman Fang
> Fix For: 3.1.6, 3.2.0
>
>
> Description of the issue is in this forum post: 
> http://cxf.547215.n5.nabble.com/Setting-soap-attachment-Content-Transfer-Encoding-td3335835.html
> Attachment encoding in CXF doesn't support base64. AttachmentSerializer.class 
> in cxf-api contains the hardcoded value 
> writer.write(URLDecoder.decode(attachmentId, "UTF-8"));



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6827) OAuthRequestFilter should be able to cache token validation results

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6827.


> OAuthRequestFilter should be able to cache token validation results
> ---
>
> Key: CXF-6827
> URL: https://issues.apache.org/jira/browse/CXF-6827
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.1.6, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6809) SAMLRequest ID must not start with a Number

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6809.


> SAMLRequest ID must not start with a Number
> ---
>
> Key: CXF-6809
> URL: https://issues.apache.org/jira/browse/CXF-6809
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS Security
>Affects Versions: 2.7.18, 3.1.5, 3.0.8
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 3.1.6, 3.2.0
>
>
> According to the XML Standard a xs:ID Element must not start with a number, 
> but with a character or underscore instead.
> http://www.datypic.com/sc/xsd/t-xsd_ID.html
> Current ID generation in SAMLRequestBuilder is based on UUID generation only 
> and can produce IDs that start with a number. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6767) OSGI ServletImporter should be able to accept extra properties

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6767.


> OSGI ServletImporter should be able to accept extra properties
> --
>
> Key: CXF-6767
> URL: https://issues.apache.org/jira/browse/CXF-6767
> Project: CXF
>  Issue Type: Improvement
>  Components: OSGi, Transports
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.6, 3.2.0
>
>
> Example, Swagger specific/etc properties may need to be set up



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-5439) Introduce annotations for marking CXF interceptors and features to enable the auto-discovery

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-5439.


> Introduce annotations for marking CXF interceptors and features to enable the 
> auto-discovery
> 
>
> Key: CXF-5439
> URL: https://issues.apache.org/jira/browse/CXF-5439
> Project: CXF
>  Issue Type: Improvement
>  Components: Core
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.6, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6671) Ambiguous JAXRSServerFactoryBean.setApplication() breaks Spring injection

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6671.


> Ambiguous JAXRSServerFactoryBean.setApplication() breaks Spring injection
> -
>
> Key: CXF-6671
> URL: https://issues.apache.org/jira/browse/CXF-6671
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.7
>Reporter: Andrew Greenburg
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> We're using a custom javax.ws.rs.core.Application implementation, 
> "com.foo.BasicApplication", injected via Spring XML into a 
> JAXRSServerFactoryBean. I've been seeing some inconsistent behavior at 
> intialization. About half the time I get this:
> {code}
> WARN  [] [org.springframework.beans.GenericTypeAwarePropertyDescriptor] - 
> Invalid JavaBean property 'application' being accessed! Ambiguous write 
> methods found next to actually used [public void 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setApplication(javax.ws.rs.core.Application)]:
>  [public void 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setApplication(org.apache.cxf.jaxrs.model.ApplicationInfo)]
> {code}
> which complains about it, but in this case it still works.
> The other half of the time I get this, and the application fails to start up:
> {code}
> org.springframework.beans.ConversionNotSupportedException: Failed to convert 
> property value of type 'com.foo.BasicApplication' to required type 
> 'org.apache.cxf.jaxrs.model.ApplicationInfo' for property 'application'; 
> nested exception is java.lang.IllegalStateException: Cannot convert value of 
> type [com.foo.BasicApplication] to required type 
> [org.apache.cxf.jaxrs.model.ApplicationInfo] for property 'application': no 
> matching editors or conversion strategy found
>   at 
> org.springframework.beans.AbstractNestablePropertyAccessor.convertIfNecessary(AbstractNestablePropertyAccessor.java:591)
>   at 
> org.springframework.beans.AbstractNestablePropertyAccessor.convertForProperty(AbstractNestablePropertyAccessor.java:603)
>   at 
> org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperImpl.java:204)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.convertForProperty(AbstractAutowireCapableBeanFactory.java:1527)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1486)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1226)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>   ... 24 more
> {code}
> Is this not a supported configuration? I found a workaround of creating a 
> wrapper class that proxies the setter call without the ambiguity, but it's 
> not ideal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6693) CXF fails to parse Cookie header when it contains $ character

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6693.


> CXF fails to parse Cookie header when it contains $ character
> -
>
> Key: CXF-6693
> URL: https://issues.apache.org/jira/browse/CXF-6693
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.4
>Reporter: Thorsten Hoeger
>Assignee: Sergey Beryozkin
>Priority: Critical
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> If the Cookie header contains $ character the method getCookies in 
> org.apache.cxf.jaxrs.impl.HttpHeadersImpl in line 113 fails to parse the 
> individual cookies and returns the complete string as one cookie. Values with 
> ; character will possibly fail to in the current implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6679) @Context HttpServletRequest request.getParameterMap() can't contain post parameters by application/x-www-form-urlencoded

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6679.


>  @Context HttpServletRequest request.getParameterMap() can't contain post 
> parameters by application/x-www-form-urlencoded
> -
>
> Key: CXF-6679
> URL: https://issues.apache.org/jira/browse/CXF-6679
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.1
>Reporter: ghs
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: CxfPostParameters_.zip
>
>
>   @POST
>   @Path("/post")
>   public String post( @Context HttpServletRequest request ){
>   Map reMap = request.getParameterMap();
>   System.out.println( reMap );
>   return reMap.toString();
>   }
> In reMap, there are no post parameters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6664) NullpointerException in LinkBuilderImpl#getResolvedUri when linkheader url has a matrix parameter

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6664.


> NullpointerException in LinkBuilderImpl#getResolvedUri when linkheader url 
> has a matrix parameter
> -
>
> Key: CXF-6664
> URL: https://issues.apache.org/jira/browse/CXF-6664
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.3
>Reporter: Michael Krenn
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> The method LinkBuilderImpl#link(String) has a bug when in url between "<" and 
> ">" a matrix parameter (begins with ";") is occuring.
> Then the tokenizer splits the url at ";" and no "UriBuilder.fromUri" is 
> called.
> when accessing "ub" in getResolvedUri, a NullPointerException is thrown.
> Example:
> * LinkHeader Entry:
> ;rel="all";title="Read
>  all resources";type="application/json";verb="GET"
> * StackTrace:
> java.lang.NullPointerException
>   at 
> org.apache.cxf.jaxrs.impl.LinkBuilderImpl.getResolvedUri(LinkBuilderImpl.java:58)
>   at 
> org.apache.cxf.jaxrs.impl.LinkBuilderImpl.build(LinkBuilderImpl.java:46)
>   at javax.ws.rs.core.Link.valueOf(Link.java:174)
>   at 
> org.apache.cxf.jaxrs.impl.ResponseImpl.getAllLinks(ResponseImpl.java:362)
>   at org.apache.cxf.jaxrs.impl.ResponseImpl.getLink(ResponseImpl.java:305)
> Following Patch of "LinkBuilderImpl#link(String)" supports this case:
> @Override
> public Builder link(String link) {
> String[] tokens = StringUtils.split(link, ";");
> String potentialUrlPart = null;
> for (String token : tokens) {
> if (potentialUrlPart != null) {
> token = potentialUrlPart + token;
>   potentialUrlPart = null;
> }
> String theToken = token.trim();
> if (theToken.startsWith("<") && theToken.endsWith(">")) {
> ub = UriBuilder.fromUri(theToken.substring(1, 
> theToken.length() - 1));
> } else {
> int i = theToken.indexOf('=');
> if (i != -1) {
> String name = theToken.substring(0, i);
> String value = stripQuotes(theToken.substring(i + 1));
> params.put(name, value);
> } else {
> potentialUrlPart = token;
> }
> }
> }
> return this;
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6709) HttpServletRequest.getInputStream is empty

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6709.


> HttpServletRequest.getInputStream is empty
> --
>
> Key: CXF-6709
> URL: https://issues.apache.org/jira/browse/CXF-6709
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6668) [wadl2java] @Multipart annotation generated, @QueryParam expected

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6668.


> [wadl2java] @Multipart annotation generated, @QueryParam expected
> -
>
> Key: CXF-6668
> URL: https://issues.apache.org/jira/browse/CXF-6668
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 3.1.3
>Reporter: Alexey Markevich
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: cxf.patch, test.wadl, wadl2java-multipart-query.zip
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6677) Content-Type is empty on POST request with empty body

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6677.


> Content-Type is empty on POST request with empty body 
> --
>
> Key: CXF-6677
> URL: https://issues.apache.org/jira/browse/CXF-6677
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Pavel Kokush
>Assignee: Sergey Beryozkin
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> I have following code:
> endpoint:
> {code}@Path("/")
> @Produces(MediaType.APPLICATION_JSON)
> @Consumes(MediaType.APPLICATION_JSON)
> public interface MyApi
> {
>   @Path("invoices/{number}/bookkeep")
>   @PUT
>   String bookkeep(@PathParam("number") String invoiceNumber);
> ...
> }{code}
> client configuration:
> {code}JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress("http://localhost;);
> bean.setInheritHeaders(true);
> bean.setThreadSafe(true);
> bean.setServiceClass(MyApi.class);
> MyApi myApi = bean.create(MyApi.class);{code}
> When I run
> {code}myApi.bookkeep("111");{code}
> Result:
> {code}Http-Method: PUT
> Content-Type: 
> Headers: {Access-Token=[aaa], Accept=[application/json]}{code}
> Expected: 
> {code}...
> Content-Type: application/json
> ...{code}
> With cxf-rt-rs-client version 3.0.3 Content-Type is application/json.
> With cxf-rt-rs-client version 3.1.4 Content-Type is empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6761) JAX-RS ClientImpl does not set TLSClientParameters on HTTPConduit when only HostnameVerifier is configured

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6761.


> 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
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> 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] [Closed] (CXF-6367) JAX-RS Client runtime does not check BeanParam bean fields

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6367.


> JAX-RS Client runtime does not check BeanParam bean fields
> --
>
> Key: CXF-6367
> URL: https://issues.apache.org/jira/browse/CXF-6367
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 3.0.5
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6335) Explicitly set HTTPConduit on client inbound message

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6335.


> Explicitly set HTTPConduit on client inbound message
> 
>
> Key: CXF-6335
> URL: https://issues.apache.org/jira/browse/CXF-6335
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-WS Runtime, Transports
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
> Fix For: 3.1.0, 3.0.5
>
>
> On client side, an instance of HTTPConduit is saved in the Message when the 
> ConduitSelector is used on client (in particular, the prepare(Message 
> message) method is called on the selector). That applies to the oubound 
> message only, though. The inbound message is not explicitly linked to the 
> conduit, untill something actually needs it (lazy approach), for instance the 
> PolicyInVerificationInterceptor.
> This is a problem as the selector clears the message context cache after 
> having selected the conduit, which is a performance issue as we end up 
> computing the cache twice for response messages. The conduit should be 
> selected (actually copied from the outbound message) soon after having 
> created the response inbound Message, to prevent double cache computing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6521) RS SAML Out Interceptors should be able to reuse tokens set by STSTokenOutInterceptor

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6521.


> RS SAML Out Interceptors should be able to reuse tokens set by 
> STSTokenOutInterceptor
> -
>
> Key: CXF-6521
> URL: https://issues.apache.org/jira/browse/CXF-6521
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS Security, WS-* Components
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.1.3
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6711) Aegis Databinding Deserialization Vulnerability

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6711.


> Aegis Databinding Deserialization Vulnerability
> ---
>
> Key: CXF-6711
> URL: https://issues.apache.org/jira/browse/CXF-6711
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding
>Affects Versions: 3.1.4
>Reporter: Moritz Bechler
>Assignee: Daniel Kulp
> Fix For: 3.1.5, 3.0.8
>
>
> Just had a quick look after the topic came up on -users. Aegis Databiding 
> seems to perform unsafe deserialization when serializedWhenUnknown=true. Now 
> sure how common that is (and actually no experience with aegis at all), but 
> if used and enabled that's pretty much direct remote code execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6280) Consider providing a DirectAccessToken JAXRS service

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6280.


> Consider providing a DirectAccessToken JAXRS service
> 
>
> Key: CXF-6280
> URL: https://issues.apache.org/jira/browse/CXF-6280
> Project: CXF
>  Issue Type: Task
>  Components: JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 3.0.5
>
>
> AuthorizationCodeGrantService already allows returning a code out of band. In 
> some cases the tokens may need to be obtained out of band too, similar to 
> ImplicitGrantService. We will probably need a custom grant type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6295) String cannot be cast to org.apache.ws.security.validate.Validator

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6295.


> String cannot be cast to org.apache.ws.security.validate.Validator
> --
>
> Key: CXF-6295
> URL: https://issues.apache.org/jira/browse/CXF-6295
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
> Fix For: 3.1.0, 3.0.5
>
>
> When setting property "ws-security.ut.validator" on an endpoint, I get the 
> following exception:
> {noformat}
> 16:38:02,007 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] 
> (http-/127.0.0.1:8080-2) Interceptor for {http://test}SimpleWSS4JImpl has 
> thrown exception, unwinding now: java.lang.ClassCastException: 
> java.lang.String cannot be cast to org.apache.ws.security.validate.Validator
>   at 
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor$1.getValidator(UsernameTokenInterceptor.java:165)
>   at 
> org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:66)
>  [wss4j-1.6.15.redhat-1.jar:1.6.15.redhat-1]
>   at 
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.validateToken(UsernameTokenInterceptor.java:182)
>   at 
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.processToken(UsernameTokenInterceptor.java:90)
>   at 
> org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.handleMessage(AbstractTokenInterceptor.java:101)
>   at 
> org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.handleMessage(AbstractTokenInterceptor.java:61)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)
>   at 
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
>   at 
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131)
>   at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) 
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>   at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
>   at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) 
> [jbossws-spi-2.3.0.Final-redhat-1.jar:2.3.0.Final-redhat-1]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) 
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>  [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) 
> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) 
> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) 
> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) 
> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
>  [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>   at 
> 

[jira] [Closed] (CXF-5771) Limitation of handling bean params inside ClientProxyImpl

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-5771.


> Limitation of handling bean params inside ClientProxyImpl
> -
>
> Key: CXF-5771
> URL: https://issues.apache.org/jira/browse/CXF-5771
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.0
>Reporter: Michał P
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.5
>
>
> Method ClientProxyImpl#getValuesFromBeanParam is limited only to use 
> getters/setters, Annotations placed on fields are ignored.
> Works:
> public class Bean {
>   private String value;
>   
>   @HeaderParam("X-VALUE")
>   public void setValue(String value) { this.value = value; }
>   public String getValue() { return value; }
> }
> Doesn't work:
> public class Bean {
>   @HeaderParam("X-VALUE")
>   private String value;
>   // getters/setters
> }
> Resolution would be to search for annotations also on fields not only methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6342) Undocumented feature to pass dates as Duration in JAX-RS-search

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6342.


> Undocumented feature to pass dates as Duration in JAX-RS-search 
> 
>
> Key: CXF-6342
> URL: https://issues.apache.org/jira/browse/CXF-6342
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.0.4
>Reporter: Vjacheslav Borisov
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.5
>
>
> Occasionally found useful, but undocumented feature to pass dates as Duration 
> in JAX-RS-search. I think it should be documented in
> http://cxf.apache.org/docs/jax-rs-search.html
> {code:title=AbstractSearchConditionParser.java|borderStyle=solid}
> // is that duration?
> try {
> Date now = new Date();
> DatatypeFactory.newInstance().newDuration(value).addTo(now);
> return now;
> } catch (DatatypeConfigurationException e1) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6332) Wadl Genertion: @Description cannot be bound to field

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6332.


> Wadl Genertion: @Description cannot be bound to field
> -
>
> Key: CXF-6332
> URL: https://issues.apache.org/jira/browse/CXF-6332
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Nicolas Daniels
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>
> WadlGenerator seems to handle correctly @Description annotation on class 
> level, and so on class fields.
> However the @Description cannot be assigned to Field:
> @Target({java.lang.annotation.ElementType.TYPE, 
> java.lang.annotation.ElementType.METHOD, 
> java.lang.annotation.ElementType.PARAMETER})
> Can you change this to:
> @Target({java.lang.annotation.ElementType.TYPE, 
> java.lang.annotation.ElementType.METHOD, 
> java.lang.annotation.ElementType.PARAMETER,
> java.lang.annotation.ElementType.FIELD})



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6337) Support the redirection directly via the injected JAX-RS ServletContext context

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6337.


> Support the redirection directly via the injected JAX-RS ServletContext 
> context
> ---
>
> Key: CXF-6337
> URL: https://issues.apache.org/jira/browse/CXF-6337
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6133) Introduce Jwe and Jws exception classes to make it easier to provide dedicated JAX-RS exception mappers

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6133.


> Introduce Jwe and Jws exception classes to make it easier to provide 
> dedicated JAX-RS exception mappers
> ---
>
> Key: CXF-6133
> URL: https://issues.apache.org/jira/browse/CXF-6133
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS, JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 3.0.5
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6754) Determin Media Type in Response

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6754.


> 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] [Closed] (CXF-6320) Zero-length entity should throw 400 on pre-packaged provider

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6320.


> Zero-length entity should throw 400 on pre-packaged provider
> 
>
> Key: CXF-6320
> URL: https://issues.apache.org/jira/browse/CXF-6320
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.3
> Environment: Windows
>Reporter: Neal Hu
>Assignee: Sergey Beryozkin
> Fix For: 3.1.0, 3.0.5
>
>
> In jsp339 spec 4.2.4 Standard Entity Providers
> java.lang.Boolean, java.lang.Character, java.lang.Number Only for text/plain. 
> Corresponding
> primitive types supported via boxing/unboxing conversion.
> When reading zero-length message entities all pre-packaged MessageBodyReader 
> implementations, except
> the JAXB one and those for the (boxed) primitive types above, MUST create a 
> corresponding Java
> object that represents zero-length data. The pre-packaged JAXB and the 
> pre-packaged primitive type
> MessageBodyReader implementations MUST throw a NoContentException for 
> zero-length message
> entities.
> Request
> Content-Type:text/plain
> Accept:\*/\*
> Body:
> Method:POST
> The CTS case resource:
> @Path("character")
> @POST
> public Character character(Character character) {
> return character;
> }
> The case expect 400 instead of 200.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6343) EncryptedHeader not properly processed or generated

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6343.


> EncryptedHeader not properly processed or generated
> ---
>
> Key: CXF-6343
> URL: https://issues.apache.org/jira/browse/CXF-6343
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.0.4
>Reporter: Hugo Trippaers
>Assignee: Colm O hEigeartaigh
> Fix For: 3.1.0, 3.0.5
>
>
> We spend quite some time getting interoperability with .NET 4.5 to work. In 
> the end we managed to track down the problem to EncryptedHeader. .NET wraps 
> EncryptedData for headers in an EncryptedHeader. This can be properly 
> understood and parsed by WSS4J, however CXF will return an error first 
> telling the client that it doesn't understand the EncryptedHeader element.
> This can be fixed by adding the following 
> QName("http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd;, 
> "EncryptedHeader") to the understood headers in the AbstractTokenInterceptor
> The return path has a problem as well, the EncryptedHeaders are not generated 
> by WSS4J while they should be (if i understand the spec correctly). This 
> seems to be due to a bug in AbstractBindingBuilder where the method 
> getEncryptedParts the following snippet should have Header instead of Element 
> for headers
> List signedParts = new 
> ArrayList();
> if (parts != null) {
> isBody = parts.isBody();
> for (Header head : parts.getHeaders()) {
> WSEncryptionPart wep = new WSEncryptionPart(head.getName(),
> 
> head.getNamespace(),
> "Element");
> signedParts.add(wep);
> }
> 
> Attachments attachments = parts.getAttachments();
> if (attachments != null) {
> WSEncryptionPart wep = new 
> WSEncryptionPart("cid:Attachments", "Element");
> signedParts.add(wep);
> }
> }
> I'm more than happy to provide a patch for this, but i'm looking for a second 
> opinion on this analysis. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6374) If no OPTIONS defined , OPTIONS request will fail with 404

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6374.


> If no OPTIONS defined , OPTIONS request will fail with 404
> --
>
> Key: CXF-6374
> URL: https://issues.apache.org/jira/browse/CXF-6374
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.0, 3.0.3, 2.7.14
>Reporter: iris ding
>Assignee: Sergey Beryozkin
> Fix For: 3.1.0, 3.0.5
>
>
> My resource class is as below:
> @Path(value = "/GetTest")
> public class HttpMethodGetTest {
>   
>   @GET
>   @Path(value = "/sub")
>   public Response getSub() {
>   return Response.ok("test")
>   .header("MY-HEAD", "sub-text-plain").build();
>   }
>   @GET
>   @Path(value = "/sub")
>   @Produces(value = "text/html")
>   public Response headSub() {
>   return Response.ok("test").header("MY-HEAD", "sub-text-html")
>   .build();
>   }
>   @Path("{id}")
>   public int getAbstractResource(@PathParam("id") int id) {
>   return 1;
>   }
>   
> }
> Then if I send an OPTIONS request to http://localhost:9080//GetTest/sub 
> it fails with 404 error.
> [WARNING ] javax.ws.rs.NotFoundException: HTTP 404 Not Found
>   at 
> org.apache.cxf.jaxrs.utils.SpecExceptions.toNotFoundException(SpecExceptions.java:89)
>   at 
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toNotFoundException(ExceptionUtils.java:126)
>   at 
> org.apache.cxf.jaxrs.utils.InjectionUtils.handleParameter(InjectionUtils.java:389)
>   at 
> org.apache.cxf.jaxrs.utils.InjectionUtils.createParameterObject(InjectionUtils.java:962)
>   at 
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromUriParam(JAXRSUtils.java:1194)
>   at 
> org.apache.cxf.jaxrs.utils.JAXRSUtils.createHttpParameterValue(JAXRSUtils.java:877)
>   at 
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:852)
>   at 
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:802)
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:259)
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:85)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>   at .
> Caused by: java.lang.NumberFormatException: For input string: "sub"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:492)
>   at java.lang.Integer.valueOf(Integer.java:582)
>   at 
> org.apache.cxf.common.util.PrimitiveUtils.read(PrimitiveUtils.java:60)
>   at 
> org.apache.cxf.jaxrs.utils.InjectionUtils.handleParameter(InjectionUtils.java:377)
>   ... 27 more
> After analysis, I found out the problem is  in 
> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod,
> We can fix this via below change in this method:
> if (!candidateList.isEmpty()) {
> Map.Entry> 
> firstEntry =
> candidateList.entrySet().iterator().next();
> matchedValues.clear();
> matchedValues.putAll(firstEntry.getValue());
> OperationResourceInfo ori = firstEntry.getKey();
> if (headMethodPossible(ori.getHttpMethod(), httpMethod)) {
> LOG.info(new 
> org.apache.cxf.common.i18n.Message("GET_INSTEAD_OF_HEAD",
> BUNDLE, 
> ori.getClassResourceInfo().getServiceClass().getName(),
> 
> ori.getMethodToInvoke().getName()).toString());
> }
> if (isFineLevelLoggable) {
> LOG.fine(new 
> org.apache.cxf.common.i18n.Message("OPER_SELECTED",
> BUNDLE, ori.getMethodToInvoke().getName(),
> 
> ori.getClassResourceInfo().getServiceClass().getName()).toString());
> }
> if (!ori.isSubResourceLocator()) {
> MediaType responseMediaType = 
> intersectSortMediaTypes(acceptContentTypes,
>   
> ori.getProduceTypes(),
>   
> false).get(0);
> message.getExchange().put(Message.CONTENT_TYPE, 
> mediaTypeToString(responseMediaType,
>   
> MEDIA_TYPE_Q_PARAM,
>  

[jira] [Closed] (CXF-6716) java2ws should log a warning message for a Holder parameter annoated with WebParam.Mode.IN property

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6716.


> java2ws should log a warning message for a Holder parameter annoated with 
> WebParam.Mode.IN property
> ---
>
> Key: CXF-6716
> URL: https://issues.apache.org/jira/browse/CXF-6716
> Project: CXF
>  Issue Type: Improvement
>  Components: Simple Frontend
>Affects Versions: 3.0.7, 3.1.4
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> java2ws should print warning message for the follow method  and let user know 
> the annotation for holder parameter is invalid and treat this as inout 
> parameter by default :
> @WebService(name = "MyEchoService", targetNamespace = "urn:echo")
> public class MyEchoService {
> @WebResult(name = "result")
> public String echo(
> @WebParam(name = "message") String message,
> @WebParam(name = "paramIn", mode = WebParam.Mode.IN, header = true) 
> Holder paramIn,
> @WebParam(name = "paramOut",mode = WebParam.Mode.OUT, header = true) 
> Holder paramOut) {
> paramOut.value = "got paramIn " + paramIn.value;
> return "echo " + message;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6353) provide a not typed way to configure cxf jaxrs clients

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6353.


> provide a not typed way to configure cxf jaxrs clients
> --
>
> Key: CXF-6353
> URL: https://issues.apache.org/jira/browse/CXF-6353
> Project: CXF
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Assignee: Sergey Beryozkin
> Fix For: 3.1.0, 3.0.5
>
>
> when using jaxrs 2 client api it is quite common to desire to configure 
> timeouts (receive, connect). To do it today you need to unwrap the Client to 
> get its config then the http conduit. Would be great to be able to do it - or 
> have a client specific config - through properties of the client/client 
> builder to try to not force user of the standard API to import CXF.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6421) Slim Exchange map down

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6421.


> Slim Exchange map down
> --
>
> Key: CXF-6421
> URL: https://issues.apache.org/jira/browse/CXF-6421
> Project: CXF
>  Issue Type: Improvement
>  Components: Core
>Reporter: Alessio Soldano
>Assignee: Alessio Soldano
> Fix For: 3.1.1
>
>
> I've been experimenting a bit on slimming the Exchange map down; basically, 
> Exchange currently store a bunch of stuff that is not strictly required 
> either because there're already direct accessors the data (Bus, Service, 
> Endpoint, Binding, BindingOperationInfo) or because the data can be easily 
> retrieved using stuff that's already in the map (ServiceInfo, InterfaceInfo, 
> BindingInfo).
> This is relevant because the Exchange map is copied into the Message context 
> cache, so the slimmer it is the faster it's copied (and ofcourse we save 
> memory).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6309) Client processing exception has its cause set to the original exception wrapped in Fault

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6309.


> Client processing exception has its cause set to the original exception 
> wrapped in Fault
> 
>
> Key: CXF-6309
> URL: https://issues.apache.org/jira/browse/CXF-6309
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6345) Support Logging in JexlClaimMapper scripts

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6345.


> Support Logging in JexlClaimMapper scripts
> --
>
> Key: CXF-6345
> URL: https://issues.apache.org/jira/browse/CXF-6345
> Project: CXF
>  Issue Type: Improvement
>  Components: STS
>Affects Versions: 3.0.4, 2.7.15
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>
> To improve debugging of Jexl scripts it will be helpful to provide a logging 
> util.
> You can create log statements like this:
> {code}
> LOG:fine("Debug message");
> LOG:info("Useful information");
> LOG:warning("This is a warning");
> LOG:severe("Error message");
> {code}
> (on) Note the colon instead of the dot after LOG
> If you don't want to use the {{java.util.logging.Logger}} you can setup for 
> example a SLF4J logger like this:
> {code}
> org.slf4j.Logger logger = 
> org.slf4j.LoggerFactory.getLogger(MyMapperTest.class);
> jcm = new JexlClaimsMapper();
> jcm.getJexlEngine().getFunctions().put("LOG", logger);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6232) Refactor CXF's Atmosphere based WebSocket transport for more flexible and extensible handling

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6232.


> Refactor CXF's Atmosphere based WebSocket transport for more flexible and 
> extensible handling
> -
>
> Key: CXF-6232
> URL: https://issues.apache.org/jira/browse/CXF-6232
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 3.0.2
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.0, 3.0.5
>
>
> Currently, CXF's Atmosphere based WebSocket transport uses Atmosphere to 
> handle WebSocket processing but uses its own message-level processing such as 
> message format conversion.
> As Atmosphere provides its flexible framework to add such message format 
> conversion and there are some custom extensions, it will be useful to use 
> this feature in CXF's WebSocket transport.
> This will allow you to easily switch the message format or protocol or add a 
> customized behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6272) SCT Renew in Secure Conversation

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6272.


> SCT Renew in Secure Conversation
> 
>
> Key: CXF-6272
> URL: https://issues.apache.org/jira/browse/CXF-6272
> Project: CXF
>  Issue Type: Bug
>Reporter: Freddy Exposito
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.1.0, 3.0.5
>
> Attachments: renew-in-secure-conversation.patch
>
>
> implement SCT Renew in Secure Conversation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6389) set initialSuspend=true incorrectly when resume the asyncresponse

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6389.


> set initialSuspend=true incorrectly when resume the asyncresponse
> -
>
> Key: CXF-6389
> URL: https://issues.apache.org/jira/browse/CXF-6389
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.0, 3.0.3, 2.7.15
>Reporter: iris ding
>Assignee: Sergey Beryozkin
> Fix For: 3.1.1, 3.0.6
>
>
> My Resource class: 
> @Path("resource")
> public class Resource
> {
>public static final String RESUMED = "Response resumed";
>public static final String FALSE = "A method returned false";
>public static final String TRUE = "A method return true";
>//
>private static final AsyncResponseBlockingQueue[] stage = {
>new AsyncResponseBlockingQueue(1),
>new AsyncResponseBlockingQueue(1),
>new AsyncResponseBlockingQueue(1)};
>@GET
>@Path("suspend")
>public void suspend(@Suspended AsyncResponse asyncResponse)
>{
>   stage[0].add(asyncResponse);
>}
>
>@GET
>@Path("cancelvoid")
>public String cancel(@QueryParam("stage") String stage)
>{
>   AsyncResponse response = takeAsyncResponse(stage);
>   boolean ret = response.cancel();
>   System.out.println("*** response.cancel() 1 " + ret);
>   ret &= response.cancel();
>   System.out.println("*** response.cancel() 2 " + ret);
>   addResponse(response, stage);
>   return ret ? TRUE : FALSE;
>}
>
> @POST
>@Path("resume")
>public String resume(@QueryParam("stage") String stage, String response)
>{
>   AsyncResponse async = takeAsyncResponse(stage);
>   boolean b = resume(async, response);
>   addResponse(async, stage);
>   return b ? TRUE : FALSE;
>}
>
>  protected static AsyncResponse takeAsyncResponse(String stageId)
>{
>   return takeAsyncResponse(Integer.parseInt(stageId));
>}
>protected static AsyncResponse takeAsyncResponse(int stageId)
>{
>   final ResponseBuilder error = createErrorResponseBuilder();
>   AsyncResponse asyncResponse = null;
>   try
>   {
>  asyncResponse = stage[stageId].take();
>   }
>   catch (InterruptedException e)
>   {
>  throw new WebApplicationException(error.entity(
>  "ArrayBlockingQueue#take").build());
>   }
>   return asyncResponse;
>}
>protected static final void addResponse(AsyncResponse response, String 
> stageId)
>{
>   int id = Integer.parseInt(stageId) + 1;
>   if (id != stage.length)
>  stage[id].add(response);
>}
>protected static boolean resume(AsyncResponse takenResponse, Object 
> response)
>{
>   return takenResponse.resume(response);
>}
>protected static ResponseBuilder createErrorResponseBuilder()
>{
>   return Response.status(Status.EXPECTATION_FAILED);
>}
>}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6409) CXF web service cannot process MTOM/XOP-optimized content within a CipherValue element

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6409.


> CXF web service cannot process MTOM/XOP-optimized content within a 
> CipherValue element
> --
>
> Key: CXF-6409
> URL: https://issues.apache.org/jira/browse/CXF-6409
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.0.4
>Reporter: Dallas Vaughan
>Assignee: Colm O hEigeartaigh
> Fix For: 3.1.1, 3.0.6
>
> Attachments: decrypt-xop.patch
>
>
> When a CXF web service endpoint is configured to use WS-Security and MTOM, 
> CXF cannot handle requests from .NET and Metro clients because it cannot 
> process {{xop:Include}} elements that are children of {{enc:CipherValue}} 
> elements, as both of these clients will optimize any large encrypted 
> (base64-encoded binary) content by serializing it as a MIME part.
> This makes it impossible for .NET and Metro clients to communicate with CXF 
> endpoints which have the MTOM and encryption policies specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6397) Upgrade atmosphere to 2.3.0

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6397.


> Upgrade atmosphere to 2.3.0
> ---
>
> Key: CXF-6397
> URL: https://issues.apache.org/jira/browse/CXF-6397
> Project: CXF
>  Issue Type: Task
>  Components: Transports
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6196) Investigate how CXFBlueprintServlet can work with blueprint-no-osgi and blueprint.web

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6196.


> Investigate how CXFBlueprintServlet can work with blueprint-no-osgi and 
> blueprint.web 
> --
>
> Key: CXF-6196
> URL: https://issues.apache.org/jira/browse/CXF-6196
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.1.1
>
>
> Aries Blueprint No Osgi module does not support custom namespaces. Most 
> likely a blueprint.web module should be updated to auto-discover custom 
> NamespaceHandler on the classpath, but it can be tricky and besides Aries 
> NamespaceHandler does not even report what namespaces it supports. A hack at 
> the CXF level, possibly with some fixes at the Aries level is needed 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6431) Attachment serialization does not conform to the relevant specs

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6431.


> Attachment serialization does not conform to the relevant specs
> ---
>
> Key: CXF-6431
> URL: https://issues.apache.org/jira/browse/CXF-6431
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.0.5
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.1, 3.0.6, 2.7.17
>
>
> This was reported in
> http://cxf.547215.n5.nabble.com/SwA-Wrong-Content-Type-of-root-part-td5757786.html
> The original issue that was reported in the above message is about the wrong 
> type value set for the SOAP envelope part in a non-MTOM multipart message 
> under SOAP 1.2.
> While looking at the code, there seem to be other inconsistency as well.
> To illustrate these issues, the current behavior is shown below, where P 
> refers to the package's content-type and E refers to the envelope's 
> content-type:
> Case 1: No MTOM using SOAP 1.2
> P Content-Type: multipart/related; type="application/soap+xml"; 
> action="urn:test:greetMe"; boundary="uuid:936da01f-9abd-4d9d-80c7- 
> 02af85c822a8"; start=""; 
> start-info="application/soap+xml"; action="urn:test:greetMe"
> E Content-Type: text/xml; charset=UTF-8; type="application/soap+xml"; 
> action="urn:test:greetMe"
> Case 2: No MTOM using SOAP 1.1
> P Content-Type: multipart/related; type="text/xml"; 
> boundary="uuid:936da01f-9abd-4d9d-80c7- 02af85c822a8"; 
> start=""; start-info="text/xml"
> E Content-Type: text/xml; charset=UTF-8; type="text/xml"
> Case 3: MTOM using SOAP 1.2
> P Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:936da01f-9abd-4d9d-80c7- 02af85c822a8"; 
> start=""; start-info="application/soap+xml"; 
> action="urn:test:greetMe"
> E Content-Type: application/xop+xml; charset=UTF-8; 
> type="application/soap+xml"; action="urn:test:greetMe"
> Case 4: MTOM using SOAP 1.1
> P Content-Type: multipart/related; type="application/xop+xml"; 
> boundary="uuid:936da01f-9abd-4d9d-80c7- 02af85c822a8"; 
> start=""; start-info="text/xml"
> E Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> The issues
> 1. the content-type of E in Case 1 is wrong (the reported issue)
> 2. the type parameter in E for non-MTOM cases 1 and 2 are not needed
> 3. the start-info parameter for MTOM SOAP 1.2 case 3 does not conform to the 
> Mtom spec http://www.w3.org/TR/2005/REC-xop10-20050125/. According to this 
> spec, the action parameter is part of the start-info value and not a separate 
> property. This is also relevant for Case 1 which generates the action 
> property at P's content-type.
> We should fix this behavior but regarding issue 3, there is some concern that 
> we might need to provide an option to fallback to the old incorrect behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6391) Create JAX-WS and JAX-RS Spring Boot demo

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6391.


> Create JAX-WS and JAX-RS Spring Boot demo
> -
>
> Key: CXF-6391
> URL: https://issues.apache.org/jira/browse/CXF-6391
> Project: CXF
>  Issue Type: Task
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.1.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6361) HttpCondiut is not detecting the redirect loop properly

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6361.


> HttpCondiut is not detecting the redirect loop properly
> ---
>
> Key: CXF-6361
> URL: https://issues.apache.org/jira/browse/CXF-6361
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.0.4, 2.7.15
>Reporter: Thorben Witt
>Assignee: Sergey Beryozkin
>  Labels: easyfix
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>
> Hi all,
> in the class HTTPConduit is the detection of a redirect. I guess there is a 
> slightly problem with the detection, when the URLs are the same:
> Line 1824:
> {code:title=HTTPConduit.java|borderStyle=solid}
> boolean invalidLoopDetected = newURL.equals(lastURL); 
> if (!invalidLoopDetected) {
> // this URI was used sometime earlier
> Integer maxSameURICount = PropertyUtils.getInteger(message, 
> AUTO_REDIRECT_MAX_SAME_URI_COUNT);
> if (maxSameURICount == null || newURLCount > maxSameURICount) 
> {
> invalidLoopDetected = true;
> }
> }
> {code}
> If the URLs are the same (boolean is true), then the if part is not reached 
> and the property AUTO_REDIRECT_MAX_SAME_URI_COUNT cannot be used.
> Can you change that? I think the change is just the removal of the not-sign:
> if (invalidLoopDetected) {...}
> Best regards,
> Thorben



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6304) AuthorizationCodeGrantHandler sets the approved scopes as the requested ones

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6304.


> AuthorizationCodeGrantHandler sets the approved scopes as the requested ones
> 
>
> Key: CXF-6304
> URL: https://issues.apache.org/jira/browse/CXF-6304
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS Security
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 3.0.5
>
>
> The code grant handler sets the approved scopes as requested scopes and 
> leaves the approved scopes empty - this works because the docs imply that if 
> the approved scopes are empty it means the user has not downscoped. However 
> this makes AccessTokenRegistration.getApprovedScopes useless in case of the 
> authorization code flow. It needs to be improved/fixed to make it cleaner



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6344) Support system file location for JexlClaimMapper scripts

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6344.


> Support system file location for JexlClaimMapper scripts
> 
>
> Key: CXF-6344
> URL: https://issues.apache.org/jira/browse/CXF-6344
> Project: CXF
>  Issue Type: Improvement
>  Components: STS
>Affects Versions: 3.0.4, 2.7.15
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>
> Currently only classpath locations are supported for the jexl script. With 
> this improvement you can choose any path in your file system which read 
> permission.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6336) Client ParamConverterProvider may be lost if Client runs in the server scope

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6336.


> Client ParamConverterProvider may be lost if Client runs in the server scope
> 
>
> Key: CXF-6336
> URL: https://issues.apache.org/jira/browse/CXF-6336
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6308) Make WebSocket transport's embedded jetty mode to use atmosphere if available

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6308.


> Make WebSocket transport's embedded jetty mode to use atmosphere if available
> -
>
> Key: CXF-6308
> URL: https://issues.apache.org/jira/browse/CXF-6308
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.0, 3.0.5
>
>
> The original implementation of the embedded mode in the WebSocket transport 
> component directly used jetty and all the relevant protocol processing is 
> done specifically for jetty. 
> This patch makes this embedded mode to use atmosphere if it is available so 
> that all the custom extensions that are used by the servlet mode can also be 
> used for the embedded mode. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6478) Introduce the option to disable using query parameters to populate the form maps

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6478.


> Introduce the option to disable using query parameters to populate the form 
> maps
> 
>
> Key: CXF-6478
> URL: https://issues.apache.org/jira/browse/CXF-6478
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-RS
>Affects Versions: 3.1.1
>Reporter: Andrei Shakirin
>Assignee: Andrei Shakirin
> Fix For: 3.1.2
>
>
> Accordingly JAX-RS specification, the parameters marked with @FormParam 
> annotation can take the values from the query parameters in case if request 
> body is already consumed:
> Servlet Container section:
> "Servlet filters may trigger consumption of a request body by accessing 
> request parameters. In a servlet container the @FormParam annotation and the 
> standard entity provider for application/x-www-form-urlencoded MUST obtain 
> their values from the servlet request parameters if the request body has 
> already been consumed. Servlet APIs do not differentiate between parameters 
> in the URI and body of a request so URI-based query parameters may be 
> included in the entity parameter."
> It is reasonable default behavior, but for in some instances this may be 
> undesired.
> I would propose to introduce custom option to explicitly forbid specified 
> assumption.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6449) Upgrade Atmosphere to 2.3.2

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6449.


> Upgrade Atmosphere to 2.3.2
> ---
>
> Key: CXF-6449
> URL: https://issues.apache.org/jira/browse/CXF-6449
> Project: CXF
>  Issue Type: Task
>  Components: Transports
>Affects Versions: 3.1.1
>Reporter: Akitoshi Yoshida
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15575527#comment-15575527
 ] 

Colm O hEigeartaigh commented on CXF-7088:
--

It looks like this is a bug in CXF. From the spec for EncryptedParts:

The EncryptedParts assertion is used to specify the parts of the message that 
require confidentiality. This
assertion can be satisfied with WSS: SOAP Message Security mechanisms or by 
mechanisms out of
scope of SOAP message security, for example by sending the message over a 
secure transport protocol
like HTTPS.

This is the logic CXF follows. However, for the tokens it appears like the 
tokens themselves should be encrypted instead.

> SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being 
> accepted
> --
>
> Key: CXF-7088
> URL: https://issues.apache.org/jira/browse/CXF-7088
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Grzegorz Maczuga
>Assignee: Colm O hEigeartaigh
> Attachments: messageNoEncryption.txt, message_anonymous.txt, 
> policy.txt
>
>
> In WS-Policy that is used by service we have defined 
> 
> Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion 
> that is inside WS-Security section of the message SOAP Header should be 
> encrypted (not only signed).
> Message with SAML that is NOT encrypted is currently accepted by CXF even 
> while policy defines 
> Question is: does SAML assertion fall into "SupportingTokens" category and 
> should be encrypted as well?
> What is your view on that? Is that a bug in Neethi?
> See 
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566
> Signed, encrypted supporting tokens are Signed supporting tokens (See section 
> 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. 
> Element Encryption SHOULD be used for encrypting the supporting tokens.
> The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax 
> of sp:SignedSupportingTokens only in the name of the assertion itself. All 
> nested policy is as per the sp:SignedSupportingTokens assertion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6845) Some methods in MessageUtils prone to NPE

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6845.


> Some methods in MessageUtils prone to NPE
> -
>
> Key: CXF-6845
> URL: https://issues.apache.org/jira/browse/CXF-6845
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.9
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: CXF-6845.diff
>
>
> When attempting to upgrade Syncope 1.2 from CXF 3.0.8 to 3.0.9, I receive NPE 
> due to some methods in {{MessageUtils}} - see for example
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean 
> defaultValue) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> return defaultValue;
> }
> {code}
> As you can see, if {{m}} is NULL, NPE is thrown.
> See for reference the same method from 3.1.6:
> {code}
> public static boolean getContextualBoolean(Message m, String key, boolean 
> defaultValue) {
> if (m != null) {
> Object o = m.getContextualProperty(key);
> if (o != null) {
> return PropertyUtils.isTrue(o);
> }
> }
> return defaultValue;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6886) CXF 3.x WSRM attachments are not retransmitted

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6886.


> CXF 3.x WSRM attachments are not retransmitted
> --
>
> Key: CXF-6886
> URL: https://issues.apache.org/jira/browse/CXF-6886
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Kai Rommel
>Assignee: Akitoshi Yoshida
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: 
> 0001-WSRM-handle-attachments-for-retransmission-fixes.patch, 
> esb-ext-cxf.git-acd68897e4bc05c1676a9b12f47b9b6c1fb862e2.patch
>
>
> With CXF-4866, CXF-352 changes to the WSRM implementation were introduced.
> When Retransmission is started from RMStore, attachments get lost.
> According to the comment from Aki in CXF-6646 implementation was changed 
> regarding storing a message for retransmission.
> Soap message and attachments are stored as blob. So no need for attachments 
> table anymore.
> RMUtils was enhanced by two methods. One encodes  the soap message and the 
> attachment as multipart message, the other decodes the stored blob into soap 
> message and attachments.
> Patch is attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6463) AbstractHTTPDestination.cacheInput() throws NullPointerException if HttpServletRequest returns null for getInputStream()

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6463.


> AbstractHTTPDestination.cacheInput() throws NullPointerException if 
> HttpServletRequest returns null for getInputStream()
> 
>
> Key: CXF-6463
> URL: https://issues.apache.org/jira/browse/CXF-6463
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.1
>Reporter: Seth Leger
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> I am writing a unit test executing inside Spring 4.0's @WebApplicationContext 
> unit test framework that invokes CXFServlet. Spring's framework provides a 
> MockHttpServletRequest object that you can construct as input to a servlet 
> request/response dispatch call.
> If the incoming message body of the MockHttpServletRequest is empty, then 
> when you call getInputStream() on it, MockHttpServletRequest will return null 
> instead of returning a ServletInputStream that contains no data.
> The code under the CXFServlet doesn't appear to like this behavior and 
> crashes with a pretty mysterious stack trace:
> {noformat}
> 2015-06-15 17:29:39,399 DEBUG [main] 
> org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on 
> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor@3118ed2c
> 2015-06-15 17:29:39,400 DEBUG [main] 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - Response content type 
> is: text/plain
> 2015-06-15 17:29:39,400 DEBUG [main] 
> org.apache.cxf.ws.addressing.ContextUtils - retrieving MAPs from context 
> property javax.xml.ws.addressing.context.inbound
> 2015-06-15 17:29:39,400 DEBUG [main] 
> org.apache.cxf.ws.addressing.ContextUtils - WS-Addressing - failed to 
> retrieve Message Addressing Properties from context
> 2015-06-15 17:29:39,401 ERROR [main] org.apache.cxf.jaxrs.utils.JAXRSUtils - 
> Problem with writing the data, class java.lang.String, ContentType: text/plain
> 2015-06-15 17:29:39,402 DEBUG [main] 
> org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleFault on 
> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor@3118ed2c
> 2015-06-15 17:29:39,402 DEBUG [main] 
> org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleFault on 
> interceptor org.apache.cxf.interceptor.MessageSenderInterceptor@1b6824c1
> 2015-06-15 17:29:39,403 WARN [main] 
> org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for 
> {http://rest.web.opennms.org/}AcknowledgmentRestService has thrown exception, 
> unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleWriteException(JAXRSOutInterceptor.java:371)
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:272)
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:118)
>   at 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:81)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>   at 
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>   at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>   at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:217)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
>   at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
>   at 
> org.opennms.core.test.rest.AbstractSpringJerseyRestTestCase$1.doFilter(AbstractSpringJerseyRestTestCase.java:240)
>   at 
> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:232)
>   at 
> 

[jira] [Closed] (CXF-6933) WadlGenerator doesn't honor multiple Descriptions for same DocTarget

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6933.


> WadlGenerator doesn't honor multiple Descriptions for same DocTarget
> 
>
> Key: CXF-6933
> URL: https://issues.apache.org/jira/browse/CXF-6933
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.6
>Reporter: Mike Golod
>Assignee: Sergey Beryozkin
>Priority: Trivial
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> I have multiple Description annotations with same doctarget but different 
> lang values. WadlGenerator handleDocs method stops on the first Description 
> it finds. Wadl xsd doesn't restrict amount of documentation elements, it's 
> unbounded!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6868) empty Authorization header result in server error

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6868.


> empty Authorization header result in server error
> -
>
> Key: CXF-6868
> URL: https://issues.apache.org/jira/browse/CXF-6868
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.1.0
>Reporter: Fadi Mohsen
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> {code}
>  java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>  at java.util.ArrayList.get(ArrayList.java:429)
>  at 
> org.apache.cxf.transport.http.Headers.getAuthorization(Headers.java:512)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.setupMessage(AbstractHTTPDestination.java:384)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:236)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>  at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6855) ElementClass annotation is ignored on JAX-RS service interface when generating the WADL

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6855.


> ElementClass annotation is ignored on JAX-RS service interface when 
> generating the WADL
> ---
>
> Key: CXF-6855
> URL: https://issues.apache.org/jira/browse/CXF-6855
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.0.8
>Reporter: Stefaan Vanderheyden
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: ZoomitWadlBugTest.java, ZoomitWadlBugTest.java
>
>
> For the purpose of generating a WADL, contrary to what would be dictated by 
> best practices the "ElementClass" annotation is ignored by CXF when it is 
> placed on the JAX-RS service interface.
> The annotation must be present on the service's implementation in order for 
> the grammar section of the WADL to be generated correctly, and for the 
> response types to be correctly linked to a grammar type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6948) WebClient may cause JMX CounterRepository OOM if a request URI varies a lot

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6948.


> WebClient may cause JMX CounterRepository OOM if a request URI varies a lot  
> -
>
> Key: CXF-6948
> URL: https://issues.apache.org/jira/browse/CXF-6948
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS, Management
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6957) JAX-RS: ExceptionMapper not called for Fault

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6957.


> JAX-RS: ExceptionMapper not called for Fault
> 
>
> Key: CXF-6957
> URL: https://issues.apache.org/jira/browse/CXF-6957
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 3.1.6
>Reporter: Philipp Förmer
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Hi,
> let service be a cxf jax-rs based service which uses a cxf based soap proxy 
> client to communicate with a soap service. If the cxf soap proxy client 
> throws a org.apache.cxf.binding.soap.SoapFault, then the SoapFault is not 
> delegated to the jax-rs ExceptionMapper chain, which is for me an unexpected 
> behaviour.
> As far as I can see this is caused by:
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(...), L: 123
> * Rethrows exception directly without wrapping it into a fault, if exception 
> is of type org.apache.cxf.interceptor.Fault. SoapFault is a subclass of Fault.
> org.apache.cxf.jaxrs.JAXRSInvoker.handleFault, L:329
> * Passes the cause of the fault to ExceptionUtils.convertFaultToResponse. The 
> cause of the cxf SoapFault is null!
> org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse, L.65:
> * Is called with null "ex" parameter and immediatley returns with null, so no 
> exception mapper gets involved.
> Thank you for your support and great project,
> Philipp



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6906) UriBuilder ignores a query component if URI contains templates

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6906.


> UriBuilder ignores a query component if URI contains templates
> --
>
> Key: CXF-6906
> URL: https://issues.apache.org/jira/browse/CXF-6906
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> URIBuilder attempts to use URI.create() first and it fails (typically if a 
> template is already set in either part of the URI) then it starts parsing URI 
> itself - in the latter case it ignores the query component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6891) IOUtils.isEmpty() doesn't reinclude byte in stream.

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6891.


> IOUtils.isEmpty() doesn't reinclude byte in stream.
> ---
>
> Key: CXF-6891
> URL: https://issues.apache.org/jira/browse/CXF-6891
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS, Tooling
>Affects Versions: 3.1.6
>Reporter: Luca Tabone
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: cxf-bug.zip
>
>
> While trying to integrate Katharsis with CXF I faced a problem related to 
> IOUtils.isEmpty() method.
> When isEmpty is invoked with an InputStream that:
> 1. Is not 'mark supported' and
> 2. The 'available()' method returns '0'.
> The byte that is read from the stream (used to determine whether the stream 
> is empty or not) is not re-included back to the stream. When I explored the 
> code inside PushbackInputStream class, I found that the byte is only being 
> included inside the PushbackInputStream.buf (using unread(byte[], int, int) 
> method).
> Find attached Maven Project containing 2 test cases.
> References:
>   > IOUtils: 
> https://cxf.apache.org/javadoc/latest/org/apache/cxf/helpers/IOUtils.html
>   > PushbackInputStream: 
> https://docs.oracle.com/javase/7/docs/api/java/io/PushbackInputStream.html
>   > Katharsis.io: http://katharsis.io



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6890) "afirmative" is mispelled in debug output

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6890.


> "afirmative" is mispelled in debug output
> -
>
> Key: CXF-6890
> URL: https://issues.apache.org/jira/browse/CXF-6890
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.7.2
>Reporter: Joseph Reedick
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Affirmative is misspelled in the following DEBUG logs:
> 2016-05-03 14:55:19,310 DEBUG [HTTPConduit ]: No Trust Decider for 
> Conduit '{http://auth.org}CMSCHWProcessImpl.http-conduit'. An afirmative 
> Trust Decision is assumed.
> 2016-05-03 14:55:19,600 DEBUG [HTTPConduit ]: No Trust Decider for 
> Conduit '{http://auth.org}CMSCHWProcessImpl.http-conduit'. An afirmative 
> Trust Decision is assumed.
> 2016-05-03 14:55:24,346 DEBUG [HTTPConduit ]: No Trust Decider for 
> Conduit 
> '{http://identity.transit.incomm.com/}IdentityAPIResource.http-conduit'. An 
> afirmative Trust Decision is assumed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6877) Have @SchemaValidation working on service endpoint implementation class method

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6877.


> Have @SchemaValidation working on service endpoint implementation class method
> --
>
> Key: CXF-6877
> URL: https://issues.apache.org/jira/browse/CXF-6877
> Project: CXF
>  Issue Type: Improvement
>  Components: JAX-WS Runtime
>Affects Versions: 3.1.6, 3.0.9
>Reporter: Jim Ma
>Assignee: Jim Ma
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> To enable schema validation for a specific method , we have to annotate  
> @SchemaValidation  on service endpoint interface's method. When service 
> endpoint interface is regenerated from wsdl, these annotations will be lost 
> and we have to annotate these method again. We need an enhancement to support 
> @SchemaValidation in implementation class method to resolve this problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6884) Don't include Signature/EncryptedKey Elements if there are no references to be signed/encrypted

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6884.


> Don't include Signature/EncryptedKey Elements if there are no references to 
> be signed/encrypted
> ---
>
> Key: CXF-6884
> URL: https://issues.apache.org/jira/browse/CXF-6884
> Project: CXF
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Don't include Signature/EncryptedKey Elements if there are no references to 
> be signed/encrypted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6858) Upgrade Xalan bundle to 2.7.2_3

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6858.


> Upgrade Xalan bundle to 2.7.2_3
> ---
>
> Key: CXF-6858
> URL: https://issues.apache.org/jira/browse/CXF-6858
> Project: CXF
>  Issue Type: Task
>  Components: OSGi
>Affects Versions: 3.1.6
>Reporter: Tadayoshi Sato
>Assignee: Colm O hEigeartaigh
> Fix For: 3.0.10, 3.1.7
>
>
> Xalan ServiceMix bundle 2.7.2_3 has been released in March 2016, which 
> includes the bug fix SM-2880.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6851) JAXRS 2 Feature not supported on server side?

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6851.


> JAXRS 2 Feature not supported on server side?
> -
>
> Key: CXF-6851
> URL: https://issues.apache.org/jira/browse/CXF-6851
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.5
>Reporter: Romain Manni-Bucau
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> Hi
> maybe I missed something but seems DynamicFeatures are supported on server 
> side through @Provider but Features (JAXRS2 ones, not CXF ones) are not. This 
> prevents to reuse some logic like Moxy JAXRS integration for instance which 
> provides a hidden (for end user) ContextProvider through a 
> Feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6675) Update commons-collections from 3.2.1 to 3.2.2

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6675.


> Update commons-collections from 3.2.1 to 3.2.2
> --
>
> Key: CXF-6675
> URL: https://issues.apache.org/jira/browse/CXF-6675
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.0.5, 2.7.18, 3.1.4
>Reporter: Gary Gregory
>Assignee: Colm O hEigeartaigh
> Fix For: 3.1.5, 3.0.8
>
>
> Update commons-collections from 3.2.1 to 3.2.2.
> See 
> https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CXF-6749) Classloader leak on FileUtils.createTmpDir()

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh closed CXF-6749.


> Classloader leak on FileUtils.createTmpDir()
> 
>
> Key: CXF-6749
> URL: https://issues.apache.org/jira/browse/CXF-6749
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.7.14
> Environment: Slackware Linux 14.1 (kernel 3.10.17), Java 1.7.0_75, 
> Tomcat 7.0.39 (this is my production environment)
>Reporter: Diogo Sant'Ana
>Assignee: Daniel Kulp
>  Labels: classloader-leak
> Fix For: 3.1.5, 3.0.8
>
>
> FileUtils.createTmpDir() adds a ApplicationShutdownHook to remove the 
> recently created temp folder, creating a indirect reference to the Tomcat 
> WebappClassloader from the hook static attribute at ApplicationShutdownHooks 
> class, preventing the classloader to be collected.
> Actually, it will be collected when the JVM is turned off. But this is a web 
> application container, it won't be turn off for a while.
> I only checked this with the version I´m currently using (2.7.14), but I 
> checked the code at 3.1.x and master branches and it still the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)