[jira] [Resolved] (CXF-6830) should be able to configure the certStore key type
[
https://issues.apache.org/jira/browse/CXF-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-6830.
---
Resolution: Duplicate
> 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] [Resolved] (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 resolved CXF-6831.
---
Resolution: Fixed
Fix Version/s: 3.0.9
3.1.6
3.2.0
commit fix
http://git-wip-us.apache.org/repos/asf/cxf/commit/707fac17 for master
http://git-wip-us.apache.org/repos/asf/cxf/commit/8851b636 for 3.1.x-fixes
branch
http://git-wip-us.apache.org/repos/asf/cxf/commit/8fbce9d5 for 3.0.x-fixes
branch
> 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
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
>
> 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)
[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=15195074#comment-15195074
]
Sergey Beryozkin commented on CXF-5702:
---
Right, this issue is really about using a CXFNonSpringJaxrsServlet to load an
Application and I have a test confirming the "ignore.application.path" is
effective.
I'm not sure how what you typed is supported in TomEE - all of those extra
variations related to how Application is loaded are supported really well in
CXF but it is available from CXF 3.1.0, here is the relevant text:
"Starting from CXF 3.1.0: JaxrsServletContextInitializer will be shipped in a
cxf-rt-rs-http-sc module. This will support no-web.xml and other JAX-RS
deployments depending on the container auto-discovery mechanism as described in
a 2.3.2 section of JSR-339 (JAX-RS 2.0)."
Given that you see your servlet loaded in TomEE which depends on CXF 2.7.x, it
looks like that TomEE does have some code for it too and I guess it delegates
to a CXFServlet internally - please report this issue to TomEE and ask Romain
to set "ignore.application.path" internally to 'true', given that in CXF 2.7.x,
as per this issue, this path is not ignored by default.
> 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] [Created] (CXF-6832) Attachment content-disposition modification-date not parsed correctly
Nicolas Daniels created CXF-6832:
Summary: Attachment content-disposition modification-date not
parsed correctly
Key: CXF-6832
URL: https://issues.apache.org/jira/browse/CXF-6832
Project: CXF
Issue Type: Bug
Reporter: Nicolas Daniels
Priority: Minor
When deserializing multipart content as
org.apache.cxf.jaxrs.ext.multipart.Attachment, the
org.apache.cxf.attachment.ContentDisposition data are not correctly filled in.
Those valid fields are not set:
* creation-date date when content was created [RFC2183]
* modification-date date when content was last modified [RFC2183]
* read-date date when content was last read [RFC2183]
Exemple of Rest WebService declaration:
public void put(@PathParam("path") String path,
@Multipart(value = "file", required = false) Attachment
attachment) throws IOException {
System.out.println(attachment.getContentDisposition().getParameter("modification-date"));
--> always null
}
Actually, the REGEXP pattern used in
ContentDisposition.CD_HEADER_PARAMS_PATTERN is not correct as it doesn't
include '-' character. So the key is not 'modification-date' but rather 'date'
in the map.
--
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=15195628#comment-15195628
]
Jan Cetkovsky commented on CXF-5702:
[~sergeyb] Thank you for your help! I reported this to Romain yesterday already
and he fixed it under https://issues.apache.org/jira/browse/TOMEE-1731
> 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=15195638#comment-15195638
]
Sergey Beryozkin commented on CXF-5702:
---
Np, thanks for coordinating it, yes, Romain does work fast :-)
Cheers, Sergey
> 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)
