[jira] [Commented] (CXF-4715) WS-security encrypted elements with XPath . CXF generates wsu:Id attribute, XSD validation on Metro fails
[ https://issues.apache.org/jira/browse/CXF-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193128#comment-15193128 ] Colm O hEigeartaigh commented on CXF-4715: -- Please log a separate JIRA with a test-case to reproduce the issue. Colm. > WS-security encrypted elements with XPath . CXF generates wsu:Id attribute, > XSD validation on Metro fails > - > > Key: CXF-4715 > URL: https://issues.apache.org/jira/browse/CXF-4715 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.6.1, 2.7.1 > Environment: JDK 1.7.0_02 > Windows 7 > Tomcat 6.0.29 > Metro 1.5 / 2.2 server >Reporter: Franck WIELGUS >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.5.8, 2.6.5, 2.7.2 > > Attachments: cxf_decrypted_request.txt, cxf_request.txt, > cxf_signed_request.txt, helloclient.wsdl, metro_decrypted_request.txt, > metro_request.txt, metro_signed_request.txt > > > The problem is related to WS-security policies enforcement by a CXF client > and the generated message compared to what is expected by a Metro server when > XSD validation is turned on. > The following policy is used : > > > > > xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";> > > > //*[local-name()='inputToEncrypt'] > > > > > > CXF client encrypts the element matching the XPath expression, but it seems > to add a "wsu:Id" attribute that is not allowed by Metro (not allowed by the > XSD of "inputToEncrypt" element). When the server analyzes the request and > tries to validate the message against the XSD, the following error appears : > javax.xml.ws.WebServiceException: org.xml.sax.SAXParseException; > cvc-complex-type.3.2.2 : L'attribut 'wsu:Id' n'est pas autorisé dans > l'élément 'inputToEncrypt'. > at > com.sun.xml.ws.util.pipe.AbstractSchemaValidationTube.doProcess(AbstractSchemaValidationTube.java:242) > at > com.sun.xml.ws.util.pipe.AbstractSchemaValidationTube.processRequest(AbstractSchemaValidationTube.java:211) > at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598) > at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557) > at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542) > at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) > at > com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) > at > com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471) > at > com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) > at > com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135) > at > com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129) > at > com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160) > at > com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:722) > Caused by: org.xml.sax.SAXParseException; cvc-complex-type.3.2.2 : L'attribut > 'wsu:Id' n'est pas autorisé dans l'élément 'inputToEncrypt'. > at > com.sun.org.a
[jira] [Resolved] (CXF-6827) OAuthRequestFilter should be able to cache token validation results
[ https://issues.apache.org/jira/browse/CXF-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6827. --- Resolution: Fixed > 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.2.0, 3.1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FEDIZ-159) whr propagation can be disabled
[ https://issues.apache.org/jira/browse/FEDIZ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated FEDIZ-159: -- Fix Version/s: 1.2.3 1.3.0 > whr propagation can be disabled > --- > > Key: FEDIZ-159 > URL: https://issues.apache.org/jira/browse/FEDIZ-159 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.3 > > > The whr parameter is used by the IDP to detect which IDP should be used by > the user for authentication (home realm / requestor IDP). > Usually this whr parameter is useful for the redirected IDP to ensure that > this IDP feels responsible for the user or in cases that the redirected IDP > is also just a link in a bigger chain of IDPs. > However some IDPs might not be able to handle the whr parameter correctly and > therefore are causing problems. > If adding the whr parameter in the redirect URL can be disabled (should be > enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FEDIZ-159) whr propagation can be disabled
[ https://issues.apache.org/jira/browse/FEDIZ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-159: - Assignee: Colm O hEigeartaigh > whr propagation can be disabled > --- > > Key: FEDIZ-159 > URL: https://issues.apache.org/jira/browse/FEDIZ-159 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > > The whr parameter is used by the IDP to detect which IDP should be used by > the user for authentication (home realm / requestor IDP). > Usually this whr parameter is useful for the redirected IDP to ensure that > this IDP feels responsible for the user or in cases that the redirected IDP > is also just a link in a bigger chain of IDPs. > However some IDPs might not be able to handle the whr parameter correctly and > therefore are causing problems. > If adding the whr parameter in the redirect URL can be disabled (should be > enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-159) whr propagation can be disabled
[ https://issues.apache.org/jira/browse/FEDIZ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193549#comment-15193549 ] Colm O hEigeartaigh commented on FEDIZ-159: --- I added a property for the "TrustedIdpWSFedProtocolHandler" called "enable.home.realm" which you can set to "false" if desired. Please reopen the JIRA if this doesn't meet your requirements Colm. > whr propagation can be disabled > --- > > Key: FEDIZ-159 > URL: https://issues.apache.org/jira/browse/FEDIZ-159 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.3 > > > The whr parameter is used by the IDP to detect which IDP should be used by > the user for authentication (home realm / requestor IDP). > Usually this whr parameter is useful for the redirected IDP to ensure that > this IDP feels responsible for the user or in cases that the redirected IDP > is also just a link in a bigger chain of IDPs. > However some IDPs might not be able to handle the whr parameter correctly and > therefore are causing problems. > If adding the whr parameter in the redirect URL can be disabled (should be > enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-159) whr propagation can be disabled
[ https://issues.apache.org/jira/browse/FEDIZ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-159. --- Resolution: Fixed > whr propagation can be disabled > --- > > Key: FEDIZ-159 > URL: https://issues.apache.org/jira/browse/FEDIZ-159 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.3 > > > The whr parameter is used by the IDP to detect which IDP should be used by > the user for authentication (home realm / requestor IDP). > Usually this whr parameter is useful for the redirected IDP to ensure that > this IDP feels responsible for the user or in cases that the redirected IDP > is also just a link in a bigger chain of IDPs. > However some IDPs might not be able to handle the whr parameter correctly and > therefore are causing problems. > If adding the whr parameter in the redirect URL can be disabled (should be > enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-159) whr propagation can be disabled
[ https://issues.apache.org/jira/browse/FEDIZ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193567#comment-15193567 ] Colm O hEigeartaigh commented on FEDIZ-159: --- Renaming the property to "home.realm.propagation". Colm. > whr propagation can be disabled > --- > > Key: FEDIZ-159 > URL: https://issues.apache.org/jira/browse/FEDIZ-159 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.2.2 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.3 > > > The whr parameter is used by the IDP to detect which IDP should be used by > the user for authentication (home realm / requestor IDP). > Usually this whr parameter is useful for the redirected IDP to ensure that > this IDP feels responsible for the user or in cases that the redirected IDP > is also just a link in a bigger chain of IDPs. > However some IDPs might not be able to handle the whr parameter correctly and > therefore are causing problems. > If adding the whr parameter in the redirect URL can be disabled (should be > enabled by default), this would provide a better flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194206#comment-15194206
]
Jan Cetkovsky commented on CXF-5702:
This appears to be present in the 2.7.x (tested on 2.7.15 and 2.7.18) is there
a plan to back port this fix to the 2.7 branch?
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194267#comment-15194267
]
Sergey Beryozkin commented on CXF-5702:
---
Does setting a servlet parameter to true/false, as needed, fixes it ? All I did
was to change the default value of this parameter.
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194302#comment-15194302
]
Jan Cetkovsky commented on CXF-5702:
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to {applicationContext}/first/second
while according the spec it should get overriden and be
{applicationContext}/first only
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194302#comment-15194302
]
Jan Cetkovsky edited comment on CXF-5702 at 3/14/16 10:33 PM:
--
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to
{applicationContext}/first/second
while according the spec it should get overriden and be
{applicationContext}/first
only
was (Author: jan.cetkov...@gmail.com):
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to {applicationContext}/first/second
while according the spec it should get overriden and be
{applicationContext}/first only
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194302#comment-15194302
]
Jan Cetkovsky edited comment on CXF-5702 at 3/14/16 10:34 PM:
--
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to
bq. {applicationContext}/first/second
while according the spec it should get overriden and be
bq. {applicationContext}/first
only
was (Author: jan.cetkov...@gmail.com):
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to
{applicationContext}/first/second
while according the spec it should get overriden and be
{applicationContext}/first
only
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194302#comment-15194302
]
Jan Cetkovsky edited comment on CXF-5702 at 3/14/16 10:34 PM:
--
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to
/first/second
while according the spec it should get overriden and be
/first
only
was (Author: jan.cetkov...@gmail.com):
[~sergey_beryozkin] which servlet parameter (you mean , what would
be the key)? The issue I'm seeing in the 2.7 is if using:
com.example.MyApplication
1
com.example.MyApplication
/first
and
@ApplicationPath("/second")
public class MyApplication extends Application {
than the application gets bind to
bq. {applicationContext}/first/second
while according the spec it should get overriden and be
bq. {applicationContext}/first
only
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194308#comment-15194308
]
Sergey Beryozkin commented on CXF-5702:
---
"ignore.application.path"
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194330#comment-15194330
]
Jan Cetkovsky commented on CXF-5702:
com.example.MyApplication
1
ignore.application.path
true
com.example.MyApplication
/aaa/*
@ApplicationPath("/rs/ga/v1")
public class MyApplication extends Application {
REST Application: http://localhost:8080/registry/aaa/rs/ga/v1
-> com.example.MyApplication
doesn't seem to work on the 2.7.x . I am running it on TomEE 1.7.3 and I'm not
explicitly defining it to be CXF servlet, if it makes difference.
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194330#comment-15194330
]
Jan Cetkovsky edited comment on CXF-5702 at 3/14/16 11:17 PM:
--
com.example.MyApplication
1
ignore.application.path
true
com.example.MyApplication
/aaa/*
@ApplicationPath("/rs/ga/v1")
public class MyApplication extends Application {
REST Application: http://localhost:8080/registry/aaa/rs/ga/v1
-> com.example.MyApplication
doesn't seem to work on the 2.7.x . I am running it on TomEE 1.7.3 and I'm not
explicitly defining it to be CXF servlet, if it makes difference.
EDIT: Just tested it on TomEE 7 which has CXF 3.1.x and if this was fixed in
3.0, the problem probably lies with the openEJB wrapper there
was (Author: jan.cetkov...@gmail.com):
com.example.MyApplication
1
ignore.application.path
true
com.example.MyApplication
/aaa/*
@ApplicationPath("/rs/ga/v1")
public class MyApplication extends Application {
REST Application: http://localhost:8080/registry/aaa/rs/ga/v1
-> com.example.MyApplication
doesn't seem to work on the 2.7.x . I am running it on TomEE 1.7.3 and I'm not
explicitly defining it to be CXF servlet, if it makes difference.
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if
[jira] [Created] (CXF-6830) should be able to configure the certStore key type
Freeman Fang created CXF-6830:
-
Summary: should be able to configure the certStore key type
Key: CXF-6830
URL: https://issues.apache.org/jira/browse/CXF-6830
Project: CXF
Issue Type: Improvement
Reporter: Freeman Fang
currently we have code like
{code}
final KeyStore keyStore =
KeyStore.getInstance(KeyStore.getDefaultType());
{code}
to createTrustStore, here always use the KeyStore default type, however,
KeyStore default type would change from "jks" to "pkcs12" in java9, that said,
the KeyStore.getDefaultType() can't keep constant between different java
versions, this can cause SSL shake hand failed. we should enable the certStore
type configuration, just like the keyStore do
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6831) should be able to configure the certStore key type
Freeman Fang created CXF-6831:
-
Summary: should be able to configure the certStore key type
Key: CXF-6831
URL: https://issues.apache.org/jira/browse/CXF-6831
Project: CXF
Issue Type: Improvement
Reporter: Freeman Fang
currently we have code like
{code}
final KeyStore keyStore =
KeyStore.getInstance(KeyStore.getDefaultType());
{code}
to createTrustStore, here always use the KeyStore default type, however,
KeyStore default type would change from "jks" to "pkcs12" in java9, that said,
the KeyStore.getDefaultType() can't keep constant between different java
versions, this can cause SSL shake hand failed. we should enable the certStore
type configuration, just like the keyStore do
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6831) should be able to configure the certStore key type
[
https://issues.apache.org/jira/browse/CXF-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-6831:
-
Assignee: Freeman Fang
> should be able to configure the certStore key type
> --
>
> Key: CXF-6831
> URL: https://issues.apache.org/jira/browse/CXF-6831
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> currently we have code like
> {code}
> final KeyStore keyStore =
> KeyStore.getInstance(KeyStore.getDefaultType());
> {code}
> to createTrustStore, here always use the KeyStore default type, however,
> KeyStore default type would change from "jks" to "pkcs12" in java9, that
> said, the KeyStore.getDefaultType() can't keep constant between different
> java versions, this can cause SSL shake hand failed. we should enable the
> certStore type configuration, just like the keyStore do
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6831) should be able to configure the certStore key type
[
https://issues.apache.org/jira/browse/CXF-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated CXF-6831:
--
Description:
currently we have code like
{code}
final KeyStore keyStore =
KeyStore.getInstance(KeyStore.getDefaultType());
{code}
to createTrustStore, here always use the KeyStore default type, however,
KeyStore default type would change from "jks" to "pkcs12" in java9(see the
keystore.type property in java.security), that said, the
KeyStore.getDefaultType() can't keep constant between different java versions,
this can cause SSL shake hand failed. we should enable the certStore type
configuration, just like the keyStore do
was:
currently we have code like
{code}
final KeyStore keyStore =
KeyStore.getInstance(KeyStore.getDefaultType());
{code}
to createTrustStore, here always use the KeyStore default type, however,
KeyStore default type would change from "jks" to "pkcs12" in java9, that said,
the KeyStore.getDefaultType() can't keep constant between different java
versions, this can cause SSL shake hand failed. we should enable the certStore
type configuration, just like the keyStore do
> should be able to configure the certStore key type
> --
>
> Key: CXF-6831
> URL: https://issues.apache.org/jira/browse/CXF-6831
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
> currently we have code like
> {code}
> final KeyStore keyStore =
> KeyStore.getInstance(KeyStore.getDefaultType());
> {code}
> to createTrustStore, here always use the KeyStore default type, however,
> KeyStore default type would change from "jks" to "pkcs12" in java9(see the
> keystore.type property in java.security), that said, the
> KeyStore.getDefaultType() can't keep constant between different java
> versions, this can cause SSL shake hand failed. we should enable the
> certStore type configuration, just like the keyStore do
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
