[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492943#comment-16492943 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278398 ## File path: maven-plugins/codegen-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.codegen.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492945#comment-16492945 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278454 ## File path: maven-plugins/java2swagger-plugin/pom.xml ## @@ -33,6 +33,7 @@ 3.2.5-SNAPSHOT +org.apache.cxf.java2swagger.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492944#comment-16492944 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278420 ## File path: maven-plugins/corba/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.corbatools.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492949#comment-16492949 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278496 ## File path: maven-plugins/java2ws-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.java2ws.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492947#comment-16492947 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278476 ## File path: maven-plugins/java2wadl-plugin/pom.xml ## @@ -34,6 +34,7 @@ 3.2.5-SNAPSHOT +org.apache.cxf.java2wadl.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492950#comment-16492950 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278521 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wsdl.validator.plugin + Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492951#comment-16492951 ] ASF GitHub Bot commented on CXF-7600: - reta commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191278596 ## File path: maven-plugins/wadl2java-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wadl2java.plugin Review comment: :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492952#comment-16492952 ] ASF GitHub Bot commented on CXF-7600: - reta commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392614046 @deki @ilgrosso Thanks guys, the plugin modules have been updated, I looks better like that I think. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492967#comment-16492967 ] ASF GitHub Bot commented on CXF-7600: - reta commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392614046 @deki @ilgrosso Thanks guys, the plugin modules have been updated, it looks better like that I think. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494687#comment-16494687 ] ASF GitHub Bot commented on CXF-7600: - rmannibucau commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191642247 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.plugin.wsdl-validator Review comment: Yes :) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7512) Swagger UI does not work for CXF-DOSGi mutli bundle distro
[ https://issues.apache.org/jira/browse/CXF-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494960#comment-16494960 ] ASF GitHub Bot commented on CXF-7512: - palmpatrick commented on issue #315: [CXF-7512] Support searching swaggerUi by name and version in all bun… URL: https://github.com/apache/cxf/pull/315#issuecomment-393104816 Hi @cschneider, @sberyozkin I'm using CXF-DOSGi to host and consume both SOAP and REST services within a plain Apache Felix OSGi distribution. It works flawlessly, except for the swagger UI. What is the estimate on getting this fix reintegrated to CXF? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Swagger UI does not work for CXF-DOSGi mutli bundle distro > -- > > Key: CXF-7512 > URL: https://issues.apache.org/jira/browse/CXF-7512 > Project: CXF > Issue Type: Bug >Reporter: Christian Schneider >Assignee: Sergey Beryozkin >Priority: Major > > In karaf the swagger UI works fine but not in the multi bundle distro. > The bug is in org.apache.cxf.jaxrs.swagger.OsgiSwaggerUiResolver. There the > swagger UI is detected. Unfortunately the detection is based on the bundle > location and only works for maven uri based deployments. As the mutli bundle > distro is deployed using files it fails. > I will change the detection to scan for the swagger webbundle by detecting > the signature resource /META-INF/resources/swagger-ui. This approach should > make the detection more robust regarding different packagings and deployments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493521#comment-16493521 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191421009 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.plugin.wsdl-validator Review comment: I know it was part of my proposal but while reading it again I wonder if hyphen is allowed, because for package names it's not. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492530#comment-16492530 ] ASF GitHub Bot commented on CXF-7600: - reta commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392492633 @cschneider Right, most of our dependencies are not full-fledged Java modules (and I think it will take a long time for it to happen). Adding `Automatic-Module-Name` is a first step towards embracing JPMS by introducing consistent module names (instead of relying on the name derived from JAR file). To give you an idea, the example I posted in the description contains the declaration to dependent `Jetty` modules: ``` requires jetty.server; requires jetty.servlet; requires jetty.util; ``` Those are deducted from JAR file names. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7512) Swagger UI does not work for CXF-DOSGi mutli bundle distro
[
https://issues.apache.org/jira/browse/CXF-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495012#comment-16495012
]
ASF GitHub Bot commented on CXF-7512:
-
reta commented on a change in pull request #315: [CXF-7512] Support searching
swaggerUi by name and version in all bun…
URL: https://github.com/apache/cxf/pull/315#discussion_r191723521
##
File path:
rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/SwaggerUiResolver.java
##
@@ -87,12 +74,22 @@ protected static String checkUiRoot(String urlStr, String
swaggerUiVersion) {
}
public static String findSwaggerUiRoot(String
swaggerUiMavenGroupAndArtifact,
- String swaggerUiVersion) {
-String root =
HELPER.findSwaggerUiRootInternal(swaggerUiMavenGroupAndArtifact,
- swaggerUiVersion);
-if (root == null && HELPER.getClass() != SwaggerUiResolver.class) {
-root = new
SwaggerUiResolver().findSwaggerUiRootInternal(swaggerUiMavenGroupAndArtifact,
-
swaggerUiVersion);
+ String swaggerUiName, String
swaggerUiVersion) {
+String root = null;
+try {
+root = new OsgiSwaggerUiResolver()
+.findSwaggerUiRoot(swaggerUiMavenGroupAndArtifact,
swaggerUiVersion);
+} catch (Throwable e) {
+// Ignore
+}
+try {
Review comment:
Should it be wrapped into `if (root == null) { ... }` block (if previous
lookup succeeded)?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger UI does not work for CXF-DOSGi mutli bundle distro
> --
>
> Key: CXF-7512
> URL: https://issues.apache.org/jira/browse/CXF-7512
> Project: CXF
> Issue Type: Bug
>Reporter: Christian Schneider
>Assignee: Sergey Beryozkin
>Priority: Major
>
> In karaf the swagger UI works fine but not in the multi bundle distro.
> The bug is in org.apache.cxf.jaxrs.swagger.OsgiSwaggerUiResolver. There the
> swagger UI is detected. Unfortunately the detection is based on the bundle
> location and only works for maven uri based deployments. As the mutli bundle
> distro is deployed using files it fails.
> I will change the detection to scan for the swagger webbundle by detecting
> the signature resource /META-INF/resources/swagger-ui. This approach should
> make the detection more robust regarding different packagings and deployments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7750) cxf parent pom should have dependencyManagement entries for cxf artifacts
[
https://issues.apache.org/jira/browse/CXF-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499808#comment-16499808
]
ASF GitHub Bot commented on CXF-7750:
-
ffang closed pull request #421: CXF-7750 CXF parent pom should have
dependencyManagement entries for cxf artifacts
URL: https://github.com/apache/cxf/pull/421
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/parent/pom.xml b/parent/pom.xml
index 5367d3af283..863a9cc2302 100644
--- a/parent/pom.xml
+++ b/parent/pom.xml
@@ -640,6 +640,601 @@
+
+
+
+org.apache.cxf
+cxf-bundle-compatible
+${project.version}
+
+
+org.apache.cxf
+cxf-core
+${project.version}
+
+
+org.apache.cxf
+cxf-distribution-javadoc
+${project.version}
+
+
+org.apache.cxf
+cxf-distribution-manifest
+${project.version}
+
+
+org.apache.cxf
+cxf-integration-cdi
+${project.version}
+
+
+org.apache.cxf
+cxf-integration-tracing-htrace
+${project.version}
+
+
+org.apache.cxf
+cxf-integration-tracing-jca
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-coloc
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-corba
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-object
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-soap
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-xml
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-xml
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-bindings-xml
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-databinding-aegis
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-databinding-jaxb
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-databinding-jibx
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-databinding-sdo
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-databinding-xmlbeans
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-features-clustering
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-features-logging
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-features-metrics
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-features-throttling
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-frontend-jaxrs
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-frontend-jaxws
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-frontend-js
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-frontend-simple
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-javascript
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-javascript-tests
+${project.version}
+
+
+org.apache.cxf
+cxf-rt-management
+${project.version}
+
+
+org.apache.cxf
+
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[
https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500960#comment-16500960
]
ASF GitHub Bot commented on CXF-7600:
-
reta closed pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST
entry for Java 9 compatibility
URL: https://github.com/apache/cxf/pull/420
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/core/pom.xml b/core/pom.xml
index 0832a7b7e7c..4019e789bd4 100644
--- a/core/pom.xml
+++ b/core/pom.xml
@@ -31,6 +31,7 @@
../parent/pom.xml
+org.apache.cxf.core
org.apache.cxf.bus.osgi.CXFActivator
!org.apache.cxf.internal,
diff --git a/distribution/javadoc/pom.xml b/distribution/javadoc/pom.xml
index c93183f9cc9..aa49e9ff69d 100644
--- a/distribution/javadoc/pom.xml
+++ b/distribution/javadoc/pom.xml
@@ -30,6 +30,9 @@
3.2.5-SNAPSHOT
../../parent
+
+org.apache.cxf.javadoc
+
org.apache.cxf
diff --git a/distribution/manifest/pom.xml b/distribution/manifest/pom.xml
index 24fd9cd0f0e..53c7916ad94 100644
--- a/distribution/manifest/pom.xml
+++ b/distribution/manifest/pom.xml
@@ -33,6 +33,7 @@
true
${project.version}
+org.apache.cxf.manifest
diff --git a/integration/cdi/pom.xml b/integration/cdi/pom.xml
index 077a1e88891..b2e22730a34 100644
--- a/integration/cdi/pom.xml
+++ b/integration/cdi/pom.xml
@@ -32,6 +32,7 @@
+org.apache.cxf.cdi
javax.servlet*;version="${cxf.osgi.javax.servlet.version}",
javax.enterprise*;version="${cxf.cda.api.osgi.range}",
diff --git a/integration/jca/pom.xml b/integration/jca/pom.xml
index 8096170d4c3..fe63da879d7 100644
--- a/integration/jca/pom.xml
+++ b/integration/jca/pom.xml
@@ -30,6 +30,9 @@
3.2.5-SNAPSHOT
../../parent/pom.xml
+
+org.apache.cxf.jca
+
junit
diff --git a/integration/spring-boot/autoconfigure/pom.xml
b/integration/spring-boot/autoconfigure/pom.xml
index f5a243ee123..ea8903ccc03 100644
--- a/integration/spring-boot/autoconfigure/pom.xml
+++ b/integration/spring-boot/autoconfigure/pom.xml
@@ -30,6 +30,9 @@
3.2.5-SNAPSHOT
../../../parent/pom.xml
+
+
org.apache.cxf.spring.boot.autoconfigure
+
diff --git a/integration/spring-boot/starter-jaxrs/pom.xml
b/integration/spring-boot/starter-jaxrs/pom.xml
index 76d528fdcc6..3ca0945dc18 100644
--- a/integration/spring-boot/starter-jaxrs/pom.xml
+++ b/integration/spring-boot/starter-jaxrs/pom.xml
@@ -30,6 +30,9 @@
3.2.5-SNAPSHOT
../../../parent/pom.xml
+
+org.apache.cxf.spring.boot.jaxrs
+
org.springframework.boot
diff --git a/integration/spring-boot/starter-jaxws/pom.xml
b/integration/spring-boot/starter-jaxws/pom.xml
index 775ded4aa6e..9e544848550 100644
--- a/integration/spring-boot/starter-jaxws/pom.xml
+++ b/integration/spring-boot/starter-jaxws/pom.xml
@@ -30,6 +30,9 @@
3.2.5-SNAPSHOT
../../../parent/pom.xml
+
+org.apache.cxf.spring.boot.jaxws
+
org.springframework.boot
diff --git a/integration/tracing/tracing-brave/pom.xml
b/integration/tracing/tracing-brave/pom.xml
index 0a2ea937e65..5738ca5bdaf 100644
--- a/integration/tracing/tracing-brave/pom.xml
+++ b/integration/tracing/tracing-brave/pom.xml
@@ -32,6 +32,7 @@
+org.apache.cxf.tracing.brave
org.apache.cxf.tracing,
org.apache.cxf.tracing.brave,
diff --git a/integration/tracing/tracing-htrace/pom.xml
b/integration/tracing/tracing-htrace/pom.xml
index 47481d08c4f..97fef6c20b6 100644
--- a/integration/tracing/tracing-htrace/pom.xml
+++ b/integration/tracing/tracing-htrace/pom.xml
@@ -32,6 +32,7 @@
+org.apache.cxf.tracing.htrace
org.apache.cxf.tracing
diff --git a/integration/tracing/tracing-opentracing/pom.xml
b/integration/tracing/tracing-opentracing/pom.xml
index ce1274dbea5..c173a72f725 100644
--- a/integration/tracing/tracing-opentracing/pom.xml
+++ b/integration/tracing/tracing-opentracing/pom.xml
@@ -32,6 +32,7 @@
+org.apache.cxf.tracing.opentracing
org.apache.cxf.tracing,
org.apache.cxf.tracing.opentracing,
diff --git a/maven-plugins/codegen-plugin/pom.xml
b/maven-plugins/codegen-plugin/pom.xml
index 80d0d9035c1..33799e9b364 100644
--- a/maven-plugins/codegen-plugin/pom.xml
+++
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498645#comment-16498645 ] ASF GitHub Bot commented on CXF-7600: - reta commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-394025516 @cschneider What do you think about this PR? Good to go? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7750) cxf parent pom should have dependencyManagement entries for cxf artifacts
[ https://issues.apache.org/jira/browse/CXF-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497932#comment-16497932 ] ASF GitHub Bot commented on CXF-7750: - cunningt opened a new pull request #421: CXF-7750 CXF parent pom should have dependencyManagement entries for cxf artifacts URL: https://github.com/apache/cxf/pull/421 https://issues.apache.org/jira/browse/CXF-7750 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > cxf parent pom should have dependencyManagement entries for cxf artifacts > - > > Key: CXF-7750 > URL: https://issues.apache.org/jira/browse/CXF-7750 > Project: CXF > Issue Type: Improvement > Components: Samples >Reporter: Tom Cunningham >Priority: Major > > The cxf parent pom should have dependencyManagement entries for all of the > cxf artifacts. Other projects like camel > ([https://github.com/apache/camel/blob/18a110cc4e78968b623564fe02484d54af7f906f/parent/pom.xml)] > include these so that the parent pom can be imported like a BOM and provide > standard versions of all the artifacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-5052) Classpath references should be understood using wsdlRoot batch processing options in cxf-codegen
[
https://issues.apache.org/jira/browse/CXF-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501714#comment-16501714
]
ASF GitHub Bot commented on CXF-5052:
-
deki commented on issue #384: [CXF-5052] Classpath references should be
understood using wsdlRoot batch processing options in cxf-codegen
URL: https://github.com/apache/cxf/pull/384#issuecomment-394696962
@oli-ver this could be part of the 3.2.5 release. are you able to finish it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Classpath references should be understood using wsdlRoot batch processing
> options in cxf-codegen
>
>
> Key: CXF-5052
> URL: https://issues.apache.org/jira/browse/CXF-5052
> Project: CXF
> Issue Type: Improvement
> Components: Tooling
>Affects Versions: 2.7.5
> Environment: All
>Reporter: Zach Melnick
>Priority: Major
>
> The generated client code should be able to reference a relative classpath
> rather than an absolute one when using the wsdlRoot option to generate
> clients and services via the cxf-codegen plugin.
> Relative classpaths can be specified when using the non-batch processing
> wsdlLocation options. This can be done when using something like
> classpath:wsdl/foo.wsdl.
> However, using the classpath reference in wsdlRoot does not work in the same
> fashion.
> classpath:wsdl/ should be able to find the wsdl
> directory in ${basedir}/src/main/resources/wsdl, and generate the clients
> with a wsdlLocation value relative to the classpath, making the behavior
> between and consistant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7746) Swagger2Feature - SwaggerUiResolver & JBoss 7.0 EAP
[
https://issues.apache.org/jira/browse/CXF-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501741#comment-16501741
]
ASF GitHub Bot commented on CXF-7746:
-
deki closed pull request #422: CXF-7746 Swagger2Feature - SwaggerUiResolver &
JBoss 7.0 EAP
URL: https://github.com/apache/cxf/pull/422
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/SwaggerUiResolver.java
b/rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/SwaggerUiResolver.java
index 331e9f35643..d6b306d6870 100644
---
a/rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/SwaggerUiResolver.java
+++
b/rt/rs/description-swagger-ui/src/main/java/org/apache/cxf/jaxrs/swagger/SwaggerUiResolver.java
@@ -58,19 +58,15 @@ public String findSwaggerUiRootInternal(String
swaggerUiMavenGroupAndArtifact,
protected static String checkUiRoot(String urlStr, String
swaggerUiVersion) {
int swaggerUiIndex = urlStr.lastIndexOf("/swagger-ui-");
-if (swaggerUiIndex != -1) {
-boolean urlEndsWithJarSep = urlStr.endsWith(".jar!/");
-if (urlEndsWithJarSep || urlStr.endsWith(".jar")) {
-int offset = urlEndsWithJarSep ? 6 : 4;
-String version = urlStr.substring(swaggerUiIndex + 12,
urlStr.length() - offset);
-if (swaggerUiVersion != null &&
!swaggerUiVersion.equals(version)) {
-return null;
-}
-if (!urlEndsWithJarSep) {
-urlStr = "jar:" + urlStr + "!/";
-}
-return urlStr + UI_RESOURCES_ROOT_START + version + "/";
+if (swaggerUiIndex != -1 && urlStr.matches("^.*\\.jar!?/?$")) {
+String version = urlStr.substring(swaggerUiIndex + 12,
urlStr.lastIndexOf(".jar"));
+if (swaggerUiVersion != null && !swaggerUiVersion.equals(version))
{
+return null;
+}
+if (!urlStr.endsWith("/")) {
+urlStr = "jar:" + urlStr + "!/";
}
+return urlStr + UI_RESOURCES_ROOT_START + version + "/";
}
return null;
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger2Feature - SwaggerUiResolver & JBoss 7.0 EAP
> ---
>
> Key: CXF-7746
> URL: https://issues.apache.org/jira/browse/CXF-7746
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.4
>Reporter: Etienne Dumont
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.2.5
>
>
> Hi,
> Same problem as CXF-7474, but for JBoss EAP 7.0 & CXF 3.2.4.
> The SwaggerUiResolver is not able to find the swagger-ui jar, included in our
> war via maven; the path returned by the class loader ends with ".jar/"
> instead of the expected ".jar" or ".jar!/".
> To bypass the problem, we modified the checkUiRoot as follow:
> {code:java}
> // Artifact: cxf-rt-rs-service-description-swagger
> // Class: org.apache.cxf.jaxrs.swagger.SwaggerUiResolver
> protected static String checkUiRoot(String urlStr, String swaggerUiVersion)
> {
> int swaggerUiIndex = urlStr.lastIndexOf("/swagger-ui-");
> if (swaggerUiIndex != -1)
> {
> boolean urlEndsWithJarSep = urlStr.endsWith(".jar!/");
> int offset = -1;
> if (urlEndsWithJarSep || urlStr.endsWith(".jar"))
> {
> offset = urlEndsWithJarSep ? 6 : 4;
> }
> else if (urlStr.endsWith(".jar/"))
> {
> offset = 5;
> urlEndsWithJarSep = true;
> }
> if (offset > -1)
> {
> String version = urlStr.substring(swaggerUiIndex + 12, urlStr.length()
> - offset);
> if (swaggerUiVersion != null && !swaggerUiVersion.equals(version))
> {
> return null;
> }
> else
> {
> if (!urlEndsWithJarSep)
> {
> urlStr = "jar:" + urlStr + "!/";
> }
> return urlStr + "META-INF/resources/webjars/swagger-ui/" + version +
> "/";
> }
> }
> }
> return null;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7455) IndexOutOfBoundsException when message part is missing
[
https://issues.apache.org/jira/browse/CXF-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501715#comment-16501715
]
ASF GitHub Bot commented on CXF-7455:
-
deki commented on issue #297: [CXF-7455] Tolerate missing message part
URL: https://github.com/apache/cxf/pull/297#issuecomment-394697684
@semancik any chance to get the SOAP message that reproduces the issue?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> IndexOutOfBoundsException when message part is missing
> --
>
> Key: CXF-7455
> URL: https://issues.apache.org/jira/browse/CXF-7455
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: Radovan Semancik
>Priority: Major
>
> When SOAP response from the server does not include a part which is defined
> in the WSDL, the the following exception is thrown:
> {code}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
> at
> org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
> ...
> {code}
> Yes, this is violation of the specs. Parts should not be missing. However,
> there are bad servers out there (e.g. Windows 2008 WinRM). Throwing exception
> like this prohibits the client to handle the situation. Which breaks projects
> such as winrm4j when talking to old windows boxes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7317) Non-URL encoded Content-Id href does not seem be serialized by CXF's AttachmentSerializer
[
https://issues.apache.org/jira/browse/CXF-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501709#comment-16501709
]
ASF GitHub Bot commented on CXF-7317:
-
deki closed pull request #408: [CXF-7317] Non-URL encoded Content-Id href does
not seem be serialized by CXF's AttachmentSerializer
URL: https://github.com/apache/cxf/pull/408
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
b/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
index df94235483a..3a86c406c5f 100644
--- a/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
+++ b/core/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
@@ -24,7 +24,6 @@
import java.io.OutputStream;
import java.io.StringWriter;
import java.io.Writer;
-import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;
import java.util.Collections;
import java.util.Iterator;
@@ -215,7 +214,7 @@ private void writeHeaders(String contentType, String
attachmentId,
if (attachmentId != null) {
attachmentId = checkAngleBrackets(attachmentId);
writer.write("Content-ID: <");
-writer.write(URLDecoder.decode(attachmentId,
StandardCharsets.UTF_8.name()));
+writer.write(attachmentId);
writer.write(">\r\n");
}
// headers like Content-Disposition need to be serialized
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Non-URL encoded Content-Id href does not seem be serialized by CXF's
> AttachmentSerializer
> -
>
> Key: CXF-7317
> URL: https://issues.apache.org/jira/browse/CXF-7317
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.10
>Reporter: Viral Gohel
>Priority: Major
> Fix For: 3.2.5
>
> Attachments: mtomExample.war
>
>
> CXF-6484 states that,
> >> URL-encoded content ID for MTOM attachments causes problems with web
> >> service clients. This is effectively a regression on:
> https://issues.apache.org/jira/browse/CXF-2669
> For example, If the namespace is "https://cxf.apache.org/; for the service
> endpoint, then the content id is now:
> 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F
> It was previously:
> 5726d366-df25-4945-9f3b-3003a2ae8a7...@cxf.apache.org
> Hence,
> Actual results:
> Content Id contains the full namespace (as URL) which is URL encoded:
> 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F
> Expected results:
> Content id does not require encoding and only contains hostname:
> 5726d366-df25-4945-9f3b-3003a2ae8a7...@cxf.apache.org
> With the attached reproducer, here's what the results looks like,
> Actual Result -
> href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19
> Expected Result -
> href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19
> The difference here compared to the fix for CXF-6484, is that a non-url
> encoded href using namespace with 'urn:' for the attachments is used.
> For example, like the below in the @WebService class,
> @WebService(targetNamespace = "urn:wsc.td.com/cis/2010/01/19")
> To me, it seems that the fix for CXF-6484 does not work for non-url encoded
> href.
> I.e After the fix of CXF-6484,
> Actual Result -
> href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19
> Expected Result -
> href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19
> It looks like CXF's AttachmentSerializer is not able to serialize the forward
> slashes(/) or the AttachmentUtil needs to be changed.
> I am not sure if the proper urn: namespaces should be of format, i.e
> urn:com.namespace.someResource or it can be also like,
> urn:com/namespace/someResource.
> Can we make CXF to interpret and display the href in the Content-Id with
> non-url namespace as
> cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19 ?
> instead of
> href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7746) Swagger2Feature - SwaggerUiResolver & JBoss 7.0 EAP
[
https://issues.apache.org/jira/browse/CXF-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501649#comment-16501649
]
ASF GitHub Bot commented on CXF-7746:
-
EDumdum opened a new pull request #422: CXF-7746 Swagger2Feature -
SwaggerUiResolver & JBoss 7.0 EAP
URL: https://github.com/apache/cxf/pull/422
Add support for JBoss 7.0 EAP class loader which is returning an url ending
with ".jar/" instead of the expected ".jar" or ".jar!/"
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger2Feature - SwaggerUiResolver & JBoss 7.0 EAP
> ---
>
> Key: CXF-7746
> URL: https://issues.apache.org/jira/browse/CXF-7746
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.4
>Reporter: Etienne Dumont
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.2.5
>
>
> Hi,
> Same problem as CXF-7474, but for JBoss EAP 7.0 & CXF 3.2.4.
> The SwaggerUiResolver is not able to find the swagger-ui jar, included in our
> war via maven; the path returned by the class loader ends with ".jar/"
> instead of the expected ".jar" or ".jar!/".
> To bypass the problem, we modified the checkUiRoot as follow:
> {code:java}
> // Artifact: cxf-rt-rs-service-description-swagger
> // Class: org.apache.cxf.jaxrs.swagger.SwaggerUiResolver
> protected static String checkUiRoot(String urlStr, String swaggerUiVersion)
> {
> int swaggerUiIndex = urlStr.lastIndexOf("/swagger-ui-");
> if (swaggerUiIndex != -1)
> {
> boolean urlEndsWithJarSep = urlStr.endsWith(".jar!/");
> int offset = -1;
> if (urlEndsWithJarSep || urlStr.endsWith(".jar"))
> {
> offset = urlEndsWithJarSep ? 6 : 4;
> }
> else if (urlStr.endsWith(".jar/"))
> {
> offset = 5;
> urlEndsWithJarSep = true;
> }
> if (offset > -1)
> {
> String version = urlStr.substring(swaggerUiIndex + 12, urlStr.length()
> - offset);
> if (swaggerUiVersion != null && !swaggerUiVersion.equals(version))
> {
> return null;
> }
> else
> {
> if (!urlEndsWithJarSep)
> {
> urlStr = "jar:" + urlStr + "!/";
> }
> return urlStr + "META-INF/resources/webjars/swagger-ui/" + version +
> "/";
> }
> }
> }
> return null;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7455) IndexOutOfBoundsException when message part is missing
[
https://issues.apache.org/jira/browse/CXF-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16502856#comment-16502856
]
ASF GitHub Bot commented on CXF-7455:
-
semancik commented on issue #297: [CXF-7455] Tolerate missing message part
URL: https://github.com/apache/cxf/pull/297#issuecomment-394955593
I'm sorry. I was lucky enough not to be forced to deal with that terrible
Microsoft technology in the meantime. And I'm quite scared to look there just
by myself unless I really have to. Please bear with me. But I'll do it ...
sooner or later.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> IndexOutOfBoundsException when message part is missing
> --
>
> Key: CXF-7455
> URL: https://issues.apache.org/jira/browse/CXF-7455
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.12
>Reporter: Radovan Semancik
>Priority: Major
>
> When SOAP response from the server does not include a part which is defined
> in the WSDL, the the following exception is thrown:
> {code}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
> at
> org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
> ...
> {code}
> Yes, this is violation of the specs. Parts should not be missing. However,
> there are bad servers out there (e.g. Windows 2008 WinRM). Throwing exception
> like this prohibits the client to handle the situation. Which breaks projects
> such as winrm4j when talking to old windows boxes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492198#comment-16492198 ] ASF GitHub Bot commented on CXF-7600: - reta opened a new pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420 This PR (work in progress) adds `Automatic-Module-Name` to all CXF modules in order to provide the consistent way to deal with CXF in the modern modular (JPMS-based) Java applications. The list of modules is included below: | Module | Automatic-Module-Name | | - || |cxf-manifest.jar| org.apache.cxf.manifest| |cxf-bundle-compatible-3.2.5-SNAPSHOT.jar| org.apache.cxf.bundle| |cxf-codegen-plugin-3.2.5-SNAPSHOT.jar| org.apache.cxf.codegen.plugin| |cxf-corbatools-maven-plugin-3.2.5-SNAPSHOT.jar| org.apache.cxf.corbatools.plugin| |cxf-core-3.2.5-SNAPSHOT.jar| org.apache.cxf.core| |cxf-distribution-javadoc-3.2.5-SNAPSHOT.jar| org.apache.cxf.javadoc| |cxf-integration-cdi-3.2.5-SNAPSHOT.jar| org.apache.cxf.cdi| |cxf-integration-jca-3.2.5-SNAPSHOT.jar| org.apache.cxf.jca| |cxf-integration-tracing-brave-3.2.5-SNAPSHOT.jar| org.apache.cxf.tracing.brave| |cxf-integration-tracing-htrace-3.2.5-SNAPSHOT.jar| org.apache.cxf.tracing.htrace| |cxf-integration-tracing-opentracing-3.2.5-SNAPSHOT.jar| org.apache.cxf.tracing.opentracing| |cxf-java2swagger-plugin-3.2.5-SNAPSHOT.jar| org.apache.cxf.java2swagger.plugin| |cxf-java2wadl-plugin-3.2.5-SNAPSHOT.jar| org.apache.cxf.java2wadl.plugin| |cxf-java2ws-plugin-3.2.5-SNAPSHOT.jar| org.apache.cxf.java2ws.plugin| |cxf-karaf-commands-3.2.5-SNAPSHOT.jar| org.apache.cxf.karaf.commands| |cxf-rt-bindings-coloc-3.2.5-SNAPSHOT.jar| org.apache.cxf.binding.coloc| |cxf-rt-bindings-corba-3.2.5-SNAPSHOT.jar| org.apache.cxf.binding.corba| |cxf-rt-bindings-soap-3.2.5-SNAPSHOT.jar| org.apache.cxf.binding.soap| |cxf-rt-bindings-xml-3.2.5-SNAPSHOT.jar| org.apache.cxf.binding.xml| |cxf-rt-databinding-aegis-3.2.5-SNAPSHOT.jar| org.apache.cxf.databinding.aegis| |cxf-rt-databinding-jaxb-3.2.5-SNAPSHOT.jar| org.apache.cxf.databinding.jaxb| |cxf-rt-features-clustering-3.2.5-SNAPSHOT.jar| org.apache.cxf.clustering| |cxf-rt-features-logging-3.2.5-SNAPSHOT.jar| org.apache.cxf.logging| |cxf-rt-features-metrics-3.2.5-SNAPSHOT.jar| org.apache.cxf.metrics| |cxf-rt-features-throttling-3.2.5-SNAPSHOT.jar| org.apache.cxf.throttling| |cxf-rt-frontend-jaxrs-3.2.5-SNAPSHOT.jar| org.apache.cxf.frontend.jaxrs| |cxf-rt-frontend-jaxws-3.2.5-SNAPSHOT.jar| org.apache.cxf.frontend.jaxws| |cxf-rt-frontend-js-3.2.5-SNAPSHOT.jar| org.apache.cxf.frontend.js| |cxf-rt-frontend-simple-3.2.5-SNAPSHOT.jar| org.apache.cxf.frontend.simple| |cxf-rt-javascript-3.2.5-SNAPSHOT.jar| org.apache.cxf.js| |cxf-rt-javascript-tests-3.2.5-SNAPSHOT.jar| org.apache.cxf.js.tests| |cxf-rt-management-3.2.5-SNAPSHOT.jar| org.apache.cxf.management| |cxf-rt-rs-client-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.client| |cxf-rt-rs-extension-providers-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.provider| |cxf-rt-rs-extension-reactivestreams-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.reactivestreams| |cxf-rt-rs-extension-reactor-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.reactor| |cxf-rt-rs-extension-rx2-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.rx2| |cxf-rt-rs-extension-rx-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.rx| |cxf-rt-rs-extension-search-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.search| |cxf-rt-rs-http-sci-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.sci| |cxf-rt-rs-json-basic-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.json| |cxf-rt-rs-mp-client-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.client.mp| |cxf-rt-rs-security-cors-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.cors| |cxf-rt-rs-security-jose-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.jose| |cxf-rt-rs-security-jose-jaxrs-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.jose.jaxrs| |cxf-rt-rs-security-oauth2-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.oauth2| |cxf-rt-rs-security-oauth2-saml-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.oauth2.saml| |cxf-rt-rs-security-oauth-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.oauth| |cxf-rt-rs-security-sso-oidc-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.sso.oidc| |cxf-rt-rs-security-sso-saml-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.sso.saml| |cxf-rt-rs-security-xml-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.security.xml| |cxf-rt-rs-service-description-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.wadl| |cxf-rt-rs-service-description-openapi-v3-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.openapi.v3| |cxf-rt-rs-service-description-swagger-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.swagger| |cxf-rt-rs-service-description-swagger-ui-3.2.5-SNAPSHOT.jar| org.apache.cxf.rs.swagger.ui|
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492248#comment-16492248 ] ASF GitHub Bot commented on CXF-7600: - ffang commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392413710 Hi @reta, Thanks a lot! It looks good for me! Freeman This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492252#comment-16492252 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108271 ## File path: maven-plugins/corba/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.corbatools.plugin Review comment: org.apache.cxf.plugin.corbatools This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492255#comment-16492255 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108360 ## File path: maven-plugins/java2wadl-plugin/pom.xml ## @@ -34,6 +34,7 @@ 3.2.5-SNAPSHOT +org.apache.cxf.java2wadl.plugin Review comment: org.apache.cxf.plugin.java2wadl This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492253#comment-16492253 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108512 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wsdl.validator.plugin + Review comment: org.apache.cxf.plugin.wsdl-validator This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492258#comment-16492258 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108228 ## File path: maven-plugins/codegen-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.codegen.plugin Review comment: org.apache.cxf.plugin.codegen This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492254#comment-16492254 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108439 ## File path: maven-plugins/wadl2java-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wadl2java.plugin Review comment: org.apache.cxf.plugin.wadl2java This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492257#comment-16492257 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108402 ## File path: maven-plugins/java2ws-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.java2ws.plugin Review comment: org.apache.cxf.plugin.java2ws This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492256#comment-16492256 ] ASF GitHub Bot commented on CXF-7600: - deki commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191108317 ## File path: maven-plugins/java2swagger-plugin/pom.xml ## @@ -33,6 +33,7 @@ 3.2.5-SNAPSHOT +org.apache.cxf.java2swagger.plugin Review comment: org.apache.cxf.plugin.java2swagger This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493551#comment-16493551 ] ASF GitHub Bot commented on CXF-7600: - rmannibucau commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191433130 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.plugin.wsdl-validator Review comment: It is allowed - compared to underscores or leading numbers which are not supported - but not very well integrated AFAIK in the ecosystem so avoiding it is not bad. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492307#comment-16492307 ] ASF GitHub Bot commented on CXF-7600: - rmannibucau commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191119163 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wsdl.validator.plugin + Review comment: Minus is an issue in module names so looks good IMHO This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492309#comment-16492309 ] ASF GitHub Bot commented on CXF-7600: - rmannibucau commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392430265 @cschneider it is important for users developping in j9 to have stable names even is packaging is not yet optimized. Default implicit names doesnt work well OOTB and would be broken later otherwise. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492295#comment-16492295 ] ASF GitHub Bot commented on CXF-7600: - cschneider commented on issue #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#issuecomment-392428080 Are all our dependencies already Java 9 modules? If not I do not see any use of making CXF jars modules. Not sure of course as I have not yet used modules myself. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7600) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CXF-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492306#comment-16492306 ] ASF GitHub Bot commented on CXF-7600: - rmannibucau commented on a change in pull request #420: CXF-7600: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility URL: https://github.com/apache/cxf/pull/420#discussion_r191119163 ## File path: maven-plugins/wsdl-validator-plugin/pom.xml ## @@ -29,6 +29,9 @@ cxf-maven-plugins 3.2.5-SNAPSHOT + +org.apache.cxf.wsdl.validator.plugin + Review comment: - is an issue in module names so looks good IMHO This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CXF-7600 > URL: https://issues.apache.org/jira/browse/CXF-7600 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 3.2.1 >Reporter: Dennis Kieselhorst >Assignee: Andriy Redko >Priority: Major > > See mailinglist discussion: > https://lists.apache.org/thread.html/790a276b4a7b3d977f5cb1abdc764a0529324b286fba915d19352afb@%3Cdev.cxf.apache.org%3E > Similar issues: IO-551, LANG-1338, CODEC-242 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7773) Upgrade pax-cdi to 1.0.0
[
https://issues.apache.org/jira/browse/CXF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529675#comment-16529675
]
ASF GitHub Bot commented on CXF-7773:
-
coheigea closed pull request #428: [CXF-7773] Upgrade pax-cdi to 1.0.0 (master)
URL: https://github.com/apache/cxf/pull/428
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/osgi/karaf/features/src/main/resources/features.xml
b/osgi/karaf/features/src/main/resources/features.xml
index 973a7907073..5614dadc87c 100644
--- a/osgi/karaf/features/src/main/resources/features.xml
+++ b/osgi/karaf/features/src/main/resources/features.xml
@@ -18,7 +18,7 @@
-->
http://karaf.apache.org/xmlns/features/v1.3.0;
name="cxf-${project.version}">
-
mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC2/xml/features
+
mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0/xml/features
mvn:org.apache.geronimo.specs/geronimo-osgi-registry/1.1
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Upgrade pax-cdi to 1.0.0
>
>
> Key: CXF-7773
> URL: https://issues.apache.org/jira/browse/CXF-7773
> Project: CXF
> Issue Type: Task
> Components: OSGi
>Affects Versions: 3.2.5
>Reporter: Matt Pavlovich
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.6
>
>
> pax-cdi 1.0.0 has been released
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7765) URITemplate.compareTemplates returns inconsistent results
[
https://issues.apache.org/jira/browse/CXF-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522883#comment-16522883
]
ASF GitHub Bot commented on CXF-7765:
-
svella opened a new pull request #425: CXF-7765 - URITemplate.compareTemplates
returns inconsistent results
URL: https://github.com/apache/cxf/pull/425
Proposed fix for CXF-7765
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> URITemplate.compareTemplates returns inconsistent results
> -
>
> Key: CXF-7765
> URL: https://issues.apache.org/jira/browse/CXF-7765
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.15
>Reporter: Shon Vella
>Priority: Major
>
> When org.apache.cxf.jaxrs.model.URITemplate.compareTemplates() is passed two
> templates with the same number of literal characters, it returns -1
> regardless of the order the templates a passed in. I suppose this may be on
> purpose, but the result is that if compareTemplates() is used as the basis of
> a Comparator that is used by java.util.Collections.sort() it can
> result in:
> {{java.lang.IllegalArgumentException: Comparison method violates its general
> contract!}}
> I would also expect that this would result in some degree of unpredictability
> of the prioritization of when selecting the appropriate JAX-RS method to call
> for a given request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7765) URITemplate.compareTemplates returns inconsistent results
[
https://issues.apache.org/jira/browse/CXF-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524208#comment-16524208
]
ASF GitHub Bot commented on CXF-7765:
-
coheigea closed pull request #425: CXF-7765 - URITemplate.compareTemplates
returns inconsistent results
URL: https://github.com/apache/cxf/pull/425
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/URITemplate.java
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/URITemplate.java
index b5059f3ddca..b9f0232d1a9 100644
---
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/URITemplate.java
+++
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/URITemplate.java
@@ -377,28 +377,24 @@ public static URITemplate createExactTemplate(String
pathValue) {
}
public static int compareTemplates(URITemplate t1, URITemplate t2) {
-String l1 = t1.getLiteralChars();
-String l2 = t2.getLiteralChars();
-if (!l1.equals(l2)) {
-// descending order
-return l1.length() < l2.length() ? 1 : -1;
-}
-
-int g1 = t1.getVariables().size();
-int g2 = t2.getVariables().size();
+int l1 = t1.getLiteralChars().length();
+int l2 = t2.getLiteralChars().length();
// descending order
-int result = g1 < g2 ? 1 : g1 > g2 ? -1 : 0;
+int result = l1 < l2 ? 1 : l1 > l2 ? -1 : 0;
if (result == 0) {
-int gCustom1 = t1.getCustomVariables().size();
-int gCustom2 = t2.getCustomVariables().size();
-if (gCustom1 != gCustom2) {
-// descending order
-return gCustom1 < gCustom2 ? 1 : -1;
+int g1 = t1.getVariables().size();
+int g2 = t2.getVariables().size();
+// descending order
+result = g1 < g2 ? 1 : g1 > g2 ? -1 : 0;
+if (result == 0) {
+int gCustom1 = t1.getCustomVariables().size();
+int gCustom2 = t2.getCustomVariables().size();
+result = gCustom1 < gCustom2 ? 1 : gCustom1 > gCustom2 ? -1 :
0;
+if (result == 0) {
+result =
t1.getPatternValue().compareTo(t2.getPatternValue());
+}
}
}
-if (result == 0) {
-result = t1.getPatternValue().compareTo(t2.getPatternValue());
-}
return result;
}
diff --git
a/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/model/URITemplateTest.java
b/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/model/URITemplateTest.java
index 97e53637479..7d2ac299ba0 100644
---
a/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/model/URITemplateTest.java
+++
b/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/model/URITemplateTest.java
@@ -740,4 +740,17 @@ public void testEncodeLiteralCharactersNotVariable() {
//System.out.println(ut.encodeLiteralCharacters());
assertEquals("a%20{digit:[0-9]}%20b",
ut.encodeLiteralCharacters(false));
}
+
+@Test
+public void testCompareNumberOfLiteralCharacters() {
+URITemplate t1 = new URITemplate("/foo");
+URITemplate t2 = new URITemplate("/bar");
+URITemplate t3 = new URITemplate("/foo/bar");
+assertEquals(0, URITemplate.compareTemplates(t1, t1));
+assertTrue(URITemplate.compareTemplates(t1, t3) > 0);
+assertTrue(URITemplate.compareTemplates(t3, t1) < 0);
+assertEquals(Integer.signum(URITemplate.compareTemplates(t1, t2)),
+-Integer.signum(URITemplate.compareTemplates(t2, t1)));
+}
+
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> URITemplate.compareTemplates returns inconsistent results
> -
>
> Key: CXF-7765
> URL: https://issues.apache.org/jira/browse/CXF-7765
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.15
>Reporter: Shon Vella
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.6, 3.1.17
>
>
> When org.apache.cxf.jaxrs.model.URITemplate.compareTemplates() is passed two
> templates with the same number of literal characters, it returns -1
> regardless of the order the templates a passed in. I suppose this may
[jira] [Commented] (CXF-7773) Upgrade pax-cdi to 1.0.0
[ https://issues.apache.org/jira/browse/CXF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528748#comment-16528748 ] ASF GitHub Bot commented on CXF-7773: - mattrpav opened a new pull request #427: [CXF-7773] Upgrade to pax-cdi 1.0.0 URL: https://github.com/apache/cxf/pull/427 Upgrade cxf karaf features to use pax-cdi 1.0.0 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade pax-cdi to 1.0.0 > > > Key: CXF-7773 > URL: https://issues.apache.org/jira/browse/CXF-7773 > Project: CXF > Issue Type: Task > Components: OSGi >Affects Versions: 3.2.5 >Reporter: Matt Pavlovich >Priority: Major > > pax-cdi 1.0.0 has been released -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7773) Upgrade pax-cdi to 1.0.0
[ https://issues.apache.org/jira/browse/CXF-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528750#comment-16528750 ] ASF GitHub Bot commented on CXF-7773: - mattrpav opened a new pull request #428: [CXF-7773] Upgrade pax-cdi to 1.0.0 (master) URL: https://github.com/apache/cxf/pull/428 Patch for master branch This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade pax-cdi to 1.0.0 > > > Key: CXF-7773 > URL: https://issues.apache.org/jira/browse/CXF-7773 > Project: CXF > Issue Type: Task > Components: OSGi >Affects Versions: 3.2.5 >Reporter: Matt Pavlovich >Priority: Major > > pax-cdi 1.0.0 has been released -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460638#comment-16460638
]
ASF GitHub Bot commented on CXF-7653:
-
jimma commented on issue #414: [CXF-7653]:Add system property to enable/disable
check empty response…
URL: https://github.com/apache/cxf/pull/414#issuecomment-385891859
@rmannibucau Thanks for review. You are right. I improved the code a bit,
please check if it's good now.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460592#comment-16460592
]
ASF GitHub Bot commented on CXF-7653:
-
rmannibucau commented on a change in pull request #414: [CXF-7653]:Add system
property to enable/disable check empty response…
URL: https://github.com/apache/cxf/pull/414#discussion_r185406356
##
File path: core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java
##
@@ -658,7 +659,7 @@ private void enrichFault(Fault fault) {
throw ex;
}
-if (resList == null
+if (Boolean.getBoolean(CHECK_EMTPY_RESPONSE) && resList == null
Review comment:
it goes through a Properties access so it is synchronized, maybe read it
once per client instance to avoid an useless locking?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460698#comment-16460698
]
ASF GitHub Bot commented on CXF-7653:
-
rmannibucau commented on issue #414: [CXF-7653]:Add system property to
enable/disable check empty response…
URL: https://github.com/apache/cxf/pull/414#issuecomment-385901522
Was more thinking about doing it in the constructor but works for me
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461234#comment-16461234
]
ASF GitHub Bot commented on CXF-7653:
-
coheigea commented on issue #414: [CXF-7653]:Add system property to
enable/disable check empty response…
URL: https://github.com/apache/cxf/pull/414#issuecomment-386031806
The problem with this patch is that the default behaviour is still to throw
a NPE in CXF - i.e. remove the change to the test in systests/uncategorized and
you get a NPE. Perhaps instead we need to revisit the original fix.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462028#comment-16462028
]
ASF GitHub Bot commented on CXF-7653:
-
jimma commented on issue #414: [CXF-7653]:Fix NPE in JaxWsClientProxy
URL: https://github.com/apache/cxf/pull/414#issuecomment-386207714
@coheigea I wrongly thought this was an specific issue and it isn't.
Looked at again and found this is actually caused by the null value return for
primitive type in InvocationHandler(JaxWsClientProxy) :
> If the value returned by this method is {@code null} and the interface
method's return type is
primitive, then a {@code NullPointerException} will be thrown by the
method invocation on the proxy instance.
Please review again. Thanks.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462047#comment-16462047
]
ASF GitHub Bot commented on CXF-7653:
-
jimma commented on issue #414: [CXF-7653]:Fix NPE in ClientProxy
URL: https://github.com/apache/cxf/pull/414#issuecomment-386207714
@coheigea I wrongly thought this was an specific issue and it isn't.
Looked at again and found this is actually caused by the null value return for
primitive type in InvocationHandler(ClientProxy) :
> If the value returned by this method is {@code null} and the interface
method's return type is
primitive, then a {@code NullPointerException} will be thrown by the
method invocation on the proxy instance.
Please review again. Thanks.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[
https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454453#comment-16454453
]
ASF GitHub Bot commented on CXF-7710:
-
dkulp commented on issue #409: CXF-7710: ClientImpl is memory-leak prone
URL: https://github.com/apache/cxf/pull/409#issuecomment-384696444
I think adding a method to Client like:
```
default AutoCloseable autoCloseContexts() {
return new AutoCloseable() {
@Override
public void close() throws Exception {
getRequestContext().clear();
getResponseContext().clear();
}
};
}
```
might be a useful idea. In the code, you could use the try with resources
to make sure the contexts are completely cleared:
```
try (((Client)proxy).autoCloseContexts()) {
proxy.callWhateverMethods();
}
```
Thoughts?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ClientImpl is memory-leak prone
> ---
>
> Key: CXF-7710
> URL: https://issues.apache.org/jira/browse/CXF-7710
> Project: CXF
> Issue Type: Bug
>Reporter: Facundo Velazquez
>Priority: Critical
> Attachments: heapdump_Leak_Suspects.zip, leak capture.png
>
>
> In the Mule ESB we are seeing a memory leak caused by non-released objects in
> the
> org.apache.cxf.endpoint.ClientImpl.
> After some research, I could see that the requestContext and the
> responseContext have a thread local implementation. As our code calls the
> client from different threads, in a high load scenario, lots of entries will
> be put in the requestContext map. Take into account that we clean each
> requestContext value (that is an EchoContext object), but an entry per thread
> is kept alive in the requestContext map (with an empty EchoContext map).
> You'll able to see in the attached files that this is causing a memory leak.
> Even in my tests trying to reproduce the issue, I've obtained a fatal
> OutOfMemoryError.
> Looking at the code, I've seen that the request context is a WeakHashMap,
> however the keys are threads. I supposed the purpose of this implementation
> is that entries can be removed when necessary by the garbage collector.
> However, if the threads are pooled (which is our case), strong references
> will be pointing to them, and will be never collected.
> I suppose an easy solution could be to use the thread names as keys instead
> threads objects directly. If this approach is taken, consider using string
> constructors to wrap the literal name for ensuring its garbage collection
> (since this is another well-know issue -->
> [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).]
> ).
> Another solution, that entails more changes, would be to use a Guava Cache,
> setting an expiration time.
> If the first approach is implemented, could you provide a way to clean the
> requestContext programmatically?, so in this way, we don't have to depend on
> the garbage collection process.
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[ https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454467#comment-16454467 ] ASF GitHub Bot commented on CXF-7710: - rmannibucau commented on issue #409: CXF-7710: ClientImpl is memory-leak prone URL: https://github.com/apache/cxf/pull/409#issuecomment-384700653 Yes, basically all the volatile (threadlocal) states could be closed here and the longer time cache (wsld etc) can be put in the bus or equivalent (by default) and therefore keep the client.close fast and the overall client efficient. Issue with these new API is that you can't write a portable app anymore. This is my main concern. Ensuring the client set and reset the state properly is surely saner for all consumers (native cxf, jaxws, jaxrs), no? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ClientImpl is memory-leak prone > --- > > Key: CXF-7710 > URL: https://issues.apache.org/jira/browse/CXF-7710 > Project: CXF > Issue Type: Bug >Reporter: Facundo Velazquez >Priority: Critical > Attachments: heapdump_Leak_Suspects.zip, leak capture.png > > > In the Mule ESB we are seeing a memory leak caused by non-released objects in > the > org.apache.cxf.endpoint.ClientImpl. > After some research, I could see that the requestContext and the > responseContext have a thread local implementation. As our code calls the > client from different threads, in a high load scenario, lots of entries will > be put in the requestContext map. Take into account that we clean each > requestContext value (that is an EchoContext object), but an entry per thread > is kept alive in the requestContext map (with an empty EchoContext map). > You'll able to see in the attached files that this is causing a memory leak. > Even in my tests trying to reproduce the issue, I've obtained a fatal > OutOfMemoryError. > Looking at the code, I've seen that the request context is a WeakHashMap, > however the keys are threads. I supposed the purpose of this implementation > is that entries can be removed when necessary by the garbage collector. > However, if the threads are pooled (which is our case), strong references > will be pointing to them, and will be never collected. > I suppose an easy solution could be to use the thread names as keys instead > threads objects directly. If this approach is taken, consider using string > constructors to wrap the literal name for ensuring its garbage collection > (since this is another well-know issue --> > [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).] > ). > Another solution, that entails more changes, would be to use a Guava Cache, > setting an expiration time. > If the first approach is implemented, could you provide a way to clean the > requestContext programmatically?, so in this way, we don't have to depend on > the garbage collection process. > Thank you very much. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[ https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454459#comment-16454459 ] ASF GitHub Bot commented on CXF-7710: - rmannibucau commented on issue #409: CXF-7710: ClientImpl is memory-leak prone URL: https://github.com/apache/cxf/pull/409#issuecomment-384697711 Why not closing the client for such cases if issue is the threadlocals, most of them can be cleaned up once used and re-initialied from the client at next request no? It avoids new API. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ClientImpl is memory-leak prone > --- > > Key: CXF-7710 > URL: https://issues.apache.org/jira/browse/CXF-7710 > Project: CXF > Issue Type: Bug >Reporter: Facundo Velazquez >Priority: Critical > Attachments: heapdump_Leak_Suspects.zip, leak capture.png > > > In the Mule ESB we are seeing a memory leak caused by non-released objects in > the > org.apache.cxf.endpoint.ClientImpl. > After some research, I could see that the requestContext and the > responseContext have a thread local implementation. As our code calls the > client from different threads, in a high load scenario, lots of entries will > be put in the requestContext map. Take into account that we clean each > requestContext value (that is an EchoContext object), but an entry per thread > is kept alive in the requestContext map (with an empty EchoContext map). > You'll able to see in the attached files that this is causing a memory leak. > Even in my tests trying to reproduce the issue, I've obtained a fatal > OutOfMemoryError. > Looking at the code, I've seen that the request context is a WeakHashMap, > however the keys are threads. I supposed the purpose of this implementation > is that entries can be removed when necessary by the garbage collector. > However, if the threads are pooled (which is our case), strong references > will be pointing to them, and will be never collected. > I suppose an easy solution could be to use the thread names as keys instead > threads objects directly. If this approach is taken, consider using string > constructors to wrap the literal name for ensuring its garbage collection > (since this is another well-know issue --> > [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).] > ). > Another solution, that entails more changes, would be to use a Guava Cache, > setting an expiration time. > If the first approach is implemented, could you provide a way to clean the > requestContext programmatically?, so in this way, we don't have to depend on > the garbage collection process. > Thank you very much. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7682) context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for client
[
https://issues.apache.org/jira/browse/CXF-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454428#comment-16454428
]
ASF GitHub Bot commented on CXF-7682:
-
sanaik22 opened a new pull request #394: CXF-7682:
context.get(MessageContext.HTTP_REQUEST_HEADERS) always ret…
URL: https://github.com/apache/cxf/pull/394
…urns null for client
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for
> client
> ---
>
> Key: CXF-7682
> URL: https://issues.apache.org/jira/browse/CXF-7682
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Reporter: Jimmy Praet
>Priority: Major
>
> I have a client-side LogicalHandler that adds some HTTP headers and am
> noticing it causes the existing SOAPAction HTTP header (already added
> automatically by the JAX-WS runtime) to be removed.
> My handler code looks like this:
> {code:java}
> public boolean handleMessage(LogicalMessageContext context) {
> Boolean outbound = (Boolean)
> context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
> if (outbound) {
> Map headers =
> (Map)
> context.get(MessageContext.HTTP_REQUEST_HEADERS);
> if (headers == null) {
> headers = new HashMap();
> context.put(MessageContext.HTTP_REQUEST_HEADERS, headers);
> }
> for (Map.Entry entry : Tracer.getEntries().entrySet()) {
> headers.put(entry.getKey(),
> Collections.singletonList(entry.getValue()));
> }
> }
> return true;
> }
> {code}
> I had a quick look at the code and noticed the
> [LogicalMessageContextImpl#get(Object)
> |https://github.com/apache/cxf/blob/a36af6323505211479c875fb9923cc6dcbc6ac95/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java#L53]
> always returns null on the client side (isRequestor() = true).
> So my handler will create a new header map and put it on the context, which
> is internally mapped to key "org.apache.cxf.message.Message.PROTOCOL_HEADERS"
> [here|https://github.com/apache/cxf/blob/master/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/context/WrappedMessageContext.java#L462].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7682) context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for client
[
https://issues.apache.org/jira/browse/CXF-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454430#comment-16454430
]
ASF GitHub Bot commented on CXF-7682:
-
dkulp closed pull request #394: CXF-7682:
context.get(MessageContext.HTTP_REQUEST_HEADERS) always ret…
URL: https://github.com/apache/cxf/pull/394
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
index 5fd99dcda3b..f3722f40598 100644
---
a/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
+++
b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
@@ -47,10 +47,10 @@ public Object get(Object key) {
if (((Map)o).isEmpty()) {
return null;
}
-if (!isResponse() &&
MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
+if (!isResponse() && isOutbound() &&
MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
-if (isRequestor() &&
MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
+if (isRequestor() && !isOutbound() &&
MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
}
diff --git
a/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
b/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
index d8cab8dfb8c..62bc3ce6e00 100644
--- a/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
+++ b/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
@@ -22,8 +22,12 @@
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
import java.net.URL;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.ResourceBundle;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.xml.namespace.QName;
@@ -31,6 +35,12 @@
import javax.xml.ws.BindingProvider;
import javax.xml.ws.Dispatch;
import javax.xml.ws.WebServiceException;
+import javax.xml.ws.handler.Handler;
+import javax.xml.ws.handler.LogicalHandler;
+import javax.xml.ws.handler.LogicalMessageContext;
+import javax.xml.ws.handler.MessageContext;
+import javax.xml.ws.handler.soap.SOAPHandler;
+import javax.xml.ws.handler.soap.SOAPMessageContext;
import org.apache.cxf.endpoint.Client;
import org.apache.cxf.endpoint.ClientImpl;
@@ -63,6 +73,7 @@
"SoapPort");
private final String address =
"http://localhost:9000/SoapContext/SoapPort;;
private Destination d;
+private Map headers = new HashMap<>();
@Before
public void setUp() throws Exception {
@@ -319,6 +330,89 @@ public void testClientProxyFactory() {
assertEquals("jack",
((BindingProvider)greeter3).getRequestContext().get("test"));
}
+@Test
+public void testLogicalHandler() {
+URL url = getClass().getResource("/wsdl/hello_world.wsdl");
+javax.xml.ws.Service s = javax.xml.ws.Service
+.create(url, serviceName);
+Greeter greeter = s.getPort(portName, Greeter.class);
+d.setMessageObserver(new MessageReplayObserver("sayHiResponse.xml"));
+
+List chain =
((BindingProvider)greeter).getBinding().getHandlerChain();
+chain.add(new LogicalHandler() {
+public void close(MessageContext arg0) {
+}
+
+public boolean handleFault(LogicalMessageContext arg0) {
+return true;
+}
+
+public boolean handleMessage(LogicalMessageContext context) {
+
+Boolean outbound = (Boolean)
context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
+if (outbound) {
+headers = (Map)
context.get(MessageContext.HTTP_REQUEST_HEADERS);
+if (headers == null) {
+headers = new HashMap();
+context.put(MessageContext.HTTP_REQUEST_HEADERS,
headers);
+}
+headers.put("My-Custom-Header",
Collections.singletonList("value"));
+}
+return true;
+}
+});
+((BindingProvider)greeter).getBinding().setHandlerChain(chain);
+
+String response = greeter.sayHi();
+assertNotNull(response);
+assertTrue("custom header should be present",
[jira] [Commented] (CXF-7682) context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for client
[
https://issues.apache.org/jira/browse/CXF-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454425#comment-16454425
]
ASF GitHub Bot commented on CXF-7682:
-
dkulp commented on issue #394: CXF-7682:
context.get(MessageContext.HTTP_REQUEST_HEADERS) always ret…
URL: https://github.com/apache/cxf/pull/394#issuecomment-384693086
Merging, lgtm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for
> client
> ---
>
> Key: CXF-7682
> URL: https://issues.apache.org/jira/browse/CXF-7682
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Reporter: Jimmy Praet
>Priority: Major
>
> I have a client-side LogicalHandler that adds some HTTP headers and am
> noticing it causes the existing SOAPAction HTTP header (already added
> automatically by the JAX-WS runtime) to be removed.
> My handler code looks like this:
> {code:java}
> public boolean handleMessage(LogicalMessageContext context) {
> Boolean outbound = (Boolean)
> context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
> if (outbound) {
> Map headers =
> (Map)
> context.get(MessageContext.HTTP_REQUEST_HEADERS);
> if (headers == null) {
> headers = new HashMap();
> context.put(MessageContext.HTTP_REQUEST_HEADERS, headers);
> }
> for (Map.Entry entry : Tracer.getEntries().entrySet()) {
> headers.put(entry.getKey(),
> Collections.singletonList(entry.getValue()));
> }
> }
> return true;
> }
> {code}
> I had a quick look at the code and noticed the
> [LogicalMessageContextImpl#get(Object)
> |https://github.com/apache/cxf/blob/a36af6323505211479c875fb9923cc6dcbc6ac95/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java#L53]
> always returns null on the client side (isRequestor() = true).
> So my handler will create a new header map and put it on the context, which
> is internally mapped to key "org.apache.cxf.message.Message.PROTOCOL_HEADERS"
> [here|https://github.com/apache/cxf/blob/master/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/context/WrappedMessageContext.java#L462].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[
https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454471#comment-16454471
]
ASF GitHub Bot commented on CXF-7710:
-
johnament commented on a change in pull request #409: CXF-7710: ClientImpl is
memory-leak prone
URL: https://github.com/apache/cxf/pull/409#discussion_r184449068
##
File path: core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java
##
@@ -1083,12 +1087,29 @@ public void clear() {
}
}
-
public void setExecutor(Executor executor) {
if (!SynchronousExecutor.isA(executor)) {
this.executor = executor;
}
}
+/**
+ * Returns the current thread name. As this value will be used as a key in
a {@link WeakHashMap},
+ * we should use the String constructor for avoiding scenarios where
strong references are kept
+ * to the string names causing that the map entries can't be garbage
collected.
+ * @return
+ */
+private String getThreadName() {
Review comment:
Also, you're not going to want to `new` the string each time, for
performance reasons. Can the methods that call this reduce the number of times
they call it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ClientImpl is memory-leak prone
> ---
>
> Key: CXF-7710
> URL: https://issues.apache.org/jira/browse/CXF-7710
> Project: CXF
> Issue Type: Bug
>Reporter: Facundo Velazquez
>Priority: Critical
> Attachments: heapdump_Leak_Suspects.zip, leak capture.png
>
>
> In the Mule ESB we are seeing a memory leak caused by non-released objects in
> the
> org.apache.cxf.endpoint.ClientImpl.
> After some research, I could see that the requestContext and the
> responseContext have a thread local implementation. As our code calls the
> client from different threads, in a high load scenario, lots of entries will
> be put in the requestContext map. Take into account that we clean each
> requestContext value (that is an EchoContext object), but an entry per thread
> is kept alive in the requestContext map (with an empty EchoContext map).
> You'll able to see in the attached files that this is causing a memory leak.
> Even in my tests trying to reproduce the issue, I've obtained a fatal
> OutOfMemoryError.
> Looking at the code, I've seen that the request context is a WeakHashMap,
> however the keys are threads. I supposed the purpose of this implementation
> is that entries can be removed when necessary by the garbage collector.
> However, if the threads are pooled (which is our case), strong references
> will be pointing to them, and will be never collected.
> I suppose an easy solution could be to use the thread names as keys instead
> threads objects directly. If this approach is taken, consider using string
> constructors to wrap the literal name for ensuring its garbage collection
> (since this is another well-know issue -->
> [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).]
> ).
> Another solution, that entails more changes, would be to use a Guava Cache,
> setting an expiration time.
> If the first approach is implemented, could you provide a way to clean the
> requestContext programmatically?, so in this way, we don't have to depend on
> the garbage collection process.
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7682) context.get(MessageContext.HTTP_REQUEST_HEADERS) always returns null for client
[
https://issues.apache.org/jira/browse/CXF-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454426#comment-16454426
]
ASF GitHub Bot commented on CXF-7682:
-
dkulp closed pull request #394: CXF-7682:
context.get(MessageContext.HTTP_REQUEST_HEADERS) always ret…
URL: https://github.com/apache/cxf/pull/394
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
index 5fd99dcda3b..f3722f40598 100644
---
a/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
+++
b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/logical/LogicalMessageContextImpl.java
@@ -47,10 +47,10 @@ public Object get(Object key) {
if (((Map)o).isEmpty()) {
return null;
}
-if (!isResponse() &&
MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
+if (!isResponse() && isOutbound() &&
MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
-if (isRequestor() &&
MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
+if (isRequestor() && !isOutbound() &&
MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
}
diff --git
a/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
b/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
index d8cab8dfb8c..62bc3ce6e00 100644
--- a/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
+++ b/rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/JaxWsClientTest.java
@@ -22,8 +22,12 @@
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
import java.net.URL;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.List;
import java.util.Map;
import java.util.ResourceBundle;
+import java.util.Set;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.xml.namespace.QName;
@@ -31,6 +35,12 @@
import javax.xml.ws.BindingProvider;
import javax.xml.ws.Dispatch;
import javax.xml.ws.WebServiceException;
+import javax.xml.ws.handler.Handler;
+import javax.xml.ws.handler.LogicalHandler;
+import javax.xml.ws.handler.LogicalMessageContext;
+import javax.xml.ws.handler.MessageContext;
+import javax.xml.ws.handler.soap.SOAPHandler;
+import javax.xml.ws.handler.soap.SOAPMessageContext;
import org.apache.cxf.endpoint.Client;
import org.apache.cxf.endpoint.ClientImpl;
@@ -63,6 +73,7 @@
"SoapPort");
private final String address =
"http://localhost:9000/SoapContext/SoapPort;;
private Destination d;
+private Map headers = new HashMap<>();
@Before
public void setUp() throws Exception {
@@ -319,6 +330,89 @@ public void testClientProxyFactory() {
assertEquals("jack",
((BindingProvider)greeter3).getRequestContext().get("test"));
}
+@Test
+public void testLogicalHandler() {
+URL url = getClass().getResource("/wsdl/hello_world.wsdl");
+javax.xml.ws.Service s = javax.xml.ws.Service
+.create(url, serviceName);
+Greeter greeter = s.getPort(portName, Greeter.class);
+d.setMessageObserver(new MessageReplayObserver("sayHiResponse.xml"));
+
+List chain =
((BindingProvider)greeter).getBinding().getHandlerChain();
+chain.add(new LogicalHandler() {
+public void close(MessageContext arg0) {
+}
+
+public boolean handleFault(LogicalMessageContext arg0) {
+return true;
+}
+
+public boolean handleMessage(LogicalMessageContext context) {
+
+Boolean outbound = (Boolean)
context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
+if (outbound) {
+headers = (Map)
context.get(MessageContext.HTTP_REQUEST_HEADERS);
+if (headers == null) {
+headers = new HashMap();
+context.put(MessageContext.HTTP_REQUEST_HEADERS,
headers);
+}
+headers.put("My-Custom-Header",
Collections.singletonList("value"));
+}
+return true;
+}
+});
+((BindingProvider)greeter).getBinding().setHandlerChain(chain);
+
+String response = greeter.sayHi();
+assertNotNull(response);
+assertTrue("custom header should be present",
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[
https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454457#comment-16454457
]
ASF GitHub Bot commented on CXF-7710:
-
rmannibucau commented on a change in pull request #409: CXF-7710: ClientImpl is
memory-leak prone
URL: https://github.com/apache/cxf/pull/409#discussion_r184445267
##
File path: core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java
##
@@ -1083,12 +1087,29 @@ public void clear() {
}
}
-
public void setExecutor(Executor executor) {
if (!SynchronousExecutor.isA(executor)) {
this.executor = executor;
}
}
+/**
+ * Returns the current thread name. As this value will be used as a key in
a {@link WeakHashMap},
+ * we should use the String constructor for avoiding scenarios where
strong references are kept
+ * to the string names causing that the map entries can't be garbage
collected.
+ * @return
+ */
+private String getThreadName() {
Review comment:
you probably want to use the thread id and not the name which doesn't have
to be unique?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> ClientImpl is memory-leak prone
> ---
>
> Key: CXF-7710
> URL: https://issues.apache.org/jira/browse/CXF-7710
> Project: CXF
> Issue Type: Bug
>Reporter: Facundo Velazquez
>Priority: Critical
> Attachments: heapdump_Leak_Suspects.zip, leak capture.png
>
>
> In the Mule ESB we are seeing a memory leak caused by non-released objects in
> the
> org.apache.cxf.endpoint.ClientImpl.
> After some research, I could see that the requestContext and the
> responseContext have a thread local implementation. As our code calls the
> client from different threads, in a high load scenario, lots of entries will
> be put in the requestContext map. Take into account that we clean each
> requestContext value (that is an EchoContext object), but an entry per thread
> is kept alive in the requestContext map (with an empty EchoContext map).
> You'll able to see in the attached files that this is causing a memory leak.
> Even in my tests trying to reproduce the issue, I've obtained a fatal
> OutOfMemoryError.
> Looking at the code, I've seen that the request context is a WeakHashMap,
> however the keys are threads. I supposed the purpose of this implementation
> is that entries can be removed when necessary by the garbage collector.
> However, if the threads are pooled (which is our case), strong references
> will be pointing to them, and will be never collected.
> I suppose an easy solution could be to use the thread names as keys instead
> threads objects directly. If this approach is taken, consider using string
> constructors to wrap the literal name for ensuring its garbage collection
> (since this is another well-know issue -->
> [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).]
> ).
> Another solution, that entails more changes, would be to use a Guava Cache,
> setting an expiration time.
> If the first approach is implemented, could you provide a way to clean the
> requestContext programmatically?, so in this way, we don't have to depend on
> the garbage collection process.
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[ https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454464#comment-16454464 ] ASF GitHub Bot commented on CXF-7710: - dkulp commented on issue #409: CXF-7710: ClientImpl is memory-leak prone URL: https://github.com/apache/cxf/pull/409#issuecomment-384698715 Closing the entire client is very different (which we already support). When close on the client is called, EVERYTHING gets shutdown and cleaned up including conduit connections, pointers to the WSDL's, endpoints, etc... Basically, you are saying the client is no longer going to be used. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ClientImpl is memory-leak prone > --- > > Key: CXF-7710 > URL: https://issues.apache.org/jira/browse/CXF-7710 > Project: CXF > Issue Type: Bug >Reporter: Facundo Velazquez >Priority: Critical > Attachments: heapdump_Leak_Suspects.zip, leak capture.png > > > In the Mule ESB we are seeing a memory leak caused by non-released objects in > the > org.apache.cxf.endpoint.ClientImpl. > After some research, I could see that the requestContext and the > responseContext have a thread local implementation. As our code calls the > client from different threads, in a high load scenario, lots of entries will > be put in the requestContext map. Take into account that we clean each > requestContext value (that is an EchoContext object), but an entry per thread > is kept alive in the requestContext map (with an empty EchoContext map). > You'll able to see in the attached files that this is causing a memory leak. > Even in my tests trying to reproduce the issue, I've obtained a fatal > OutOfMemoryError. > Looking at the code, I've seen that the request context is a WeakHashMap, > however the keys are threads. I supposed the purpose of this implementation > is that entries can be removed when necessary by the garbage collector. > However, if the threads are pooled (which is our case), strong references > will be pointing to them, and will be never collected. > I suppose an easy solution could be to use the thread names as keys instead > threads objects directly. If this approach is taken, consider using string > constructors to wrap the literal name for ensuring its garbage collection > (since this is another well-know issue --> > [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).] > ). > Another solution, that entails more changes, would be to use a Guava Cache, > setting an expiration time. > If the first approach is implemented, could you provide a way to clean the > requestContext programmatically?, so in this way, we don't have to depend on > the garbage collection process. > Thank you very much. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7640) Create a form to set the use of Spring in the classHelper on a per client way
[
https://issues.apache.org/jira/browse/CXF-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458149#comment-16458149
]
ASF GitHub Bot commented on CXF-7640:
-
reta closed pull request #387: [CXF-7640] Create a form to set the use of
Spring in the classHelper …
URL: https://github.com/apache/cxf/pull/387
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java
b/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java
index 4d7c9014270..91be9e8a0a9 100644
--- a/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java
+++ b/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java
@@ -19,6 +19,7 @@
package org.apache.cxf.common.util;
+
import java.lang.reflect.Proxy;
import org.apache.cxf.Bus;
@@ -28,16 +29,21 @@
*
*/
public class ClassHelper {
+
+public static final String USE_DEFAULT_CLASS_HELPER =
"org.apache.cxf.useDefaultClassHelpers";
+
static final ClassHelper HELPER;
+static final ClassHelper DEFAULT_HELPER;
+
static {
-HELPER = getClassHelper();
+DEFAULT_HELPER = new ClassHelper();
+HELPER = getClassHelper(DEFAULT_HELPER);
}
-
protected ClassHelper() {
}
-private static ClassHelper getClassHelper() {
+private static ClassHelper getClassHelper(ClassHelper defaultHelper) {
boolean useSpring = true;
String s =
SystemPropertyAction.getPropertyOrNull("org.apache.cxf.useSpringClassHelpers");
if (!StringUtils.isEmpty(s)) {
@@ -50,7 +56,7 @@ private static ClassHelper getClassHelper() {
// ignore
}
}
-return new ClassHelper();
+return defaultHelper;
}
protected Class getRealClassInternal(Object o) {
@@ -60,6 +66,7 @@ private static ClassHelper getClassHelper() {
protected Class getRealClassFromClassInternal(Class cls) {
return cls;
}
+
protected Object getRealObjectInternal(Object o) {
return o instanceof Proxy ? Proxy.getInvocationHandler(o) : o;
}
@@ -69,19 +76,38 @@ protected Object getRealObjectInternal(Object o) {
}
public static Class getRealClassFromClass(Class cls) {
-return HELPER.getRealClassFromClassInternal(cls);
+return getRealClassFromClass(null, cls);
+}
+
+public static Class getRealClassFromClass(Bus bus, Class cls) {
+bus = getBus(bus);
+return getContextClassHelper(bus).getRealClassFromClassInternal(cls);
}
public static Object getRealObject(Object o) {
-return HELPER.getRealObjectInternal(o);
+Bus bus = getBus(null);
+return getContextClassHelper(bus).getRealObjectInternal(o);
}
public static Class getRealClass(Bus bus, Object o) {
-bus = bus == null ? BusFactory.getThreadDefaultBus() : bus;
+bus = getBus(bus);
if (bus != null && bus.getProperty(ClassUnwrapper.class.getName()) !=
null) {
-ClassUnwrapper unwrapper =
(ClassUnwrapper)bus.getProperty(ClassUnwrapper.class.getName());
+ClassUnwrapper unwrapper = (ClassUnwrapper)
bus.getProperty(ClassUnwrapper.class.getName());
return unwrapper.getRealClass(o);
}
-return HELPER.getRealClassInternal(o);
+return getContextClassHelper(bus).getRealClassInternal(o);
}
+
+private static ClassHelper getContextClassHelper(Bus bus) {
+return (DEFAULT_HELPER == HELPER || checkUseDefaultClassHelper(bus)) ?
DEFAULT_HELPER : HELPER;
+}
+
+private static Bus getBus(Bus bus) {
+return bus == null ? BusFactory.getThreadDefaultBus() : bus;
+}
+
+private static boolean checkUseDefaultClassHelper(Bus bus) {
+return bus != null &&
Boolean.TRUE.equals(bus.getProperty(USE_DEFAULT_CLASS_HELPER));
+}
+
}
diff --git a/core/src/test/java/org/apache/cxf/common/util/ClassHelperTest.java
b/core/src/test/java/org/apache/cxf/common/util/ClassHelperTest.java
new file mode 100644
index 000..dc3e184b82d
--- /dev/null
+++ b/core/src/test/java/org/apache/cxf/common/util/ClassHelperTest.java
@@ -0,0 +1,169 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462551#comment-16462551
]
ASF GitHub Bot commented on CXF-7653:
-
jimma commented on a change in pull request #414: [CXF-7653]:Fix NPE in
ClientProxy
URL: https://github.com/apache/cxf/pull/414#discussion_r185826292
##
File path: core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java
##
@@ -657,24 +657,9 @@ private void enrichFault(Fault fault) {
if (ex != null) {
throw ex;
}
-
-if (resList == null
-&& oi != null && !oi.getOperationInfo().isOneWay()) {
-
-BindingOperationInfo boi = oi;
-if (boi.isUnwrapped()) {
-boi = boi.getWrappedOperation();
-}
-if (!boi.getOutput().getMessageParts().isEmpty()) {
-//we were supposed to get some output, but didn't
-throw new IllegalStateException("Response message did not
contain proper response data. Expected: "
-+
boi.getOutput().getMessageParts().get(0).getConcreteName());
-}
-}
Review comment:
> Why is all this code removed? If the WSDL states that there should be a
response and there isn't, an exception should be thrown. The above is correct.
When I ran reproducer EmptySoapBodyTest and found the NPE is thrown from
Proxy class and root cause for this NPE is a null return value for a primitive
type in InvocationHandler(ClientProxy), that's why I remove this and add this
check in ClientProxy. I only looked at EmptySoapBodayTest , any other
reproducer I need to have a look for CXF-7653 ?
Another reason why I remove these lines is this check doesn't work for this
case: for example we have a simple wsdl which generates the following operation
:
```
public HelloResponse doSomething(HelloRequest request);
```
To work with Dispatch/Provider , a provider class created to simply return
an empty StreamSource like:
```
@WebServiceProvider(
serviceName="HelloService",
portName="HelloPort",
targetNamespace="http://cxf.apache.org/provider;,
wsdlLocation="WEB-INF/hello.wsdl"
)
@BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_BINDING)
@ServiceMode (value=javax.xml.ws.Service.Mode.PAYLOAD)
public class HelloProvider implements Provider {
public Source invoke(Source req) {
return new StreamSource();
}
}
```
The client dispatch expects receiving a null value. Add this check in
ClientImpl throws IllegalStateException instead of return a null result.
> By pushing some of this down into the ClientProxy's, anything that doesn't
use the client proxies (like Camel endpoints) wouldn't have this check in place.
For the caml endpoints without using the client proxy, it gets a null value
result. Is the null value a problem for ClientCallback and something else ?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty
[jira] [Commented] (CXF-7734) Swagger2Feature - application/octet-stream media type is returned for index.html
[
https://issues.apache.org/jira/browse/CXF-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462868#comment-16462868
]
ASF GitHub Bot commented on CXF-7734:
-
deki closed pull request #416: CXF-7734 Fix media type for the root page
URL: https://github.com/apache/cxf/pull/416
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
b/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
index 7ea8d4c2220..e786c919c01 100644
---
a/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
+++
b/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
@@ -620,6 +620,7 @@ public Response getResource(@Context UriInfo uriInfo,
@PathParam("resource") Str
try {
URL resourceURL = locator.locate(resourcePath);
+resourcePath = resourceURL.getPath();
String mediaType = null;
int ind = resourcePath.lastIndexOf('.');
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger2Feature - application/octet-stream media type is returned for
> index.html
>
>
> Key: CXF-7734
> URL: https://issues.apache.org/jira/browse/CXF-7734
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.15
>Reporter: Yury Molchan
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.1.16
>
>
> Reproduced after CXF-7581.
> org.apache.cxf.jaxrs.swagger.Swagger2Feature.SwaggerUIService#getResource
> does not set media type for the root resource ("" or "/" paths)
> So, *application/octet-stream* type is set by default instead of *text/html*
> Steps to reproduce (See [Swagger2Feature - Automatic UI
> Activation|http://cxf.apache.org/docs/swaggerfeature-swagger2feature.html#SwaggerFeature/Swagger2Feature-AutomaticUIActivation]):
> * Setup Swagger2Feature
> * Open swagger-ui in a browser _$base_rest_url/api-docs?url=swagger.json_
> Actual: The file is downloading
> Expected: The index.html page is displayed
> Pull request: https://github.com/apache/cxf/pull/416
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7734) Swagger2Feature - application/octet-stream media type is returned for index.html
[
https://issues.apache.org/jira/browse/CXF-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462867#comment-16462867
]
ASF GitHub Bot commented on CXF-7734:
-
deki commented on issue #416: CXF-7734 Fix media type for the root page
URL: https://github.com/apache/cxf/pull/416#issuecomment-386384123
Thanks for the PR. I simply merged SwaggerUiService from 3.2.x where the
problem doesn't occur.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger2Feature - application/octet-stream media type is returned for
> index.html
>
>
> Key: CXF-7734
> URL: https://issues.apache.org/jira/browse/CXF-7734
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.15
>Reporter: Yury Molchan
>Assignee: Dennis Kieselhorst
>Priority: Major
> Fix For: 3.1.16
>
>
> Reproduced after CXF-7581.
> org.apache.cxf.jaxrs.swagger.Swagger2Feature.SwaggerUIService#getResource
> does not set media type for the root resource ("" or "/" paths)
> So, *application/octet-stream* type is set by default instead of *text/html*
> Steps to reproduce (See [Swagger2Feature - Automatic UI
> Activation|http://cxf.apache.org/docs/swaggerfeature-swagger2feature.html#SwaggerFeature/Swagger2Feature-AutomaticUIActivation]):
> * Setup Swagger2Feature
> * Open swagger-ui in a browser _$base_rest_url/api-docs?url=swagger.json_
> Actual: The file is downloading
> Expected: The index.html page is displayed
> Pull request: https://github.com/apache/cxf/pull/416
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7734) Swagger2Feature - application/octet-stream media type is returned for index.html
[
https://issues.apache.org/jira/browse/CXF-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462791#comment-16462791
]
ASF GitHub Bot commented on CXF-7734:
-
yurkom opened a new pull request #416: CXF-7734 Fix media type for the root page
URL: https://github.com/apache/cxf/pull/416
After migration from 3.1.14 to 3.1.15, It is impossible to see **api-docs**
page according to example in
[Swagger2Feature - Automatic UI
Activation](http://cxf.apache.org/docs/swaggerfeature-swagger2feature.html#SwaggerFeature/Swagger2Feature-AutomaticUIActivation)
This fix allows to restore this functionality.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Swagger2Feature - application/octet-stream media type is returned for
> index.html
>
>
> Key: CXF-7734
> URL: https://issues.apache.org/jira/browse/CXF-7734
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.15
>Reporter: Yury Molchan
>Priority: Major
> Fix For: 3.1.16
>
>
> Reproduced after CXF-7581.
> org.apache.cxf.jaxrs.swagger.Swagger2Feature.SwaggerUIService#getResource
> does not set media type for the root resource ("" or "/" paths)
> So, *application/octet-stream* type is set by default instead of *text/html*
> Steps to reproduce (See [Swagger2Feature - Automatic UI
> Activation|http://cxf.apache.org/docs/swaggerfeature-swagger2feature.html#SwaggerFeature/Swagger2Feature-AutomaticUIActivation]):
> * Setup Swagger2Feature
> * Open swagger-ui in a browser _$base_rest_url/api-docs?url=swagger.json_
> Actual: The file is downloading
> Expected: The index.html page is displayed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462221#comment-16462221
]
ASF GitHub Bot commented on CXF-7653:
-
andrei-ivanov commented on a change in pull request #414: [CXF-7653]:Fix NPE in
ClientProxy
URL: https://github.com/apache/cxf/pull/414#discussion_r185747189
##
File path:
rt/frontend/simple/src/main/java/org/apache/cxf/frontend/ClientProxy.java
##
@@ -79,6 +79,9 @@ public Object invoke(Object proxy, Method method, Object[]
args) throws Throwabl
}
Object o = invokeSync(method, oi, params);
+if (o == null && !method.getReturnType().equals(Void.TYPE) &&
method.getReturnType().isPrimitive()) {
Review comment:
nitpick: you can use == to check class equality
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462220#comment-16462220
]
ASF GitHub Bot commented on CXF-7653:
-
andrei-ivanov commented on a change in pull request #414: [CXF-7653]:Fix NPE in
ClientProxy
URL: https://github.com/apache/cxf/pull/414#discussion_r185747119
##
File path:
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/JaxWsClientProxy.java
##
@@ -138,6 +138,10 @@ public Object invoke(Object proxy, Method method,
Object[] args) throws Throwabl
} else {
result = invokeSync(method, oi, params);
}
+if (result == null && !method.getReturnType().equals(Void.TYPE)
Review comment:
nitpick: you can use == to check class equality
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462404#comment-16462404
]
ASF GitHub Bot commented on CXF-7653:
-
dkulp commented on a change in pull request #414: [CXF-7653]:Fix NPE in
ClientProxy
URL: https://github.com/apache/cxf/pull/414#discussion_r185790182
##
File path: core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java
##
@@ -657,24 +657,9 @@ private void enrichFault(Fault fault) {
if (ex != null) {
throw ex;
}
-
-if (resList == null
-&& oi != null && !oi.getOperationInfo().isOneWay()) {
-
-BindingOperationInfo boi = oi;
-if (boi.isUnwrapped()) {
-boi = boi.getWrappedOperation();
-}
-if (!boi.getOutput().getMessageParts().isEmpty()) {
-//we were supposed to get some output, but didn't
-throw new IllegalStateException("Response message did not
contain proper response data. Expected: "
-+
boi.getOutput().getMessageParts().get(0).getConcreteName());
-}
-}
Review comment:
Why is all this code removed?If the WSDL states that there should be a
response and there isn't, an exception should be thrown. The above is correct.
By pushing some of this down into the ClientProxy's, anything that doesn't
use the client proxies (like Camel endpoints) wouldn't have this check in place.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3, 3.2.4
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope;>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7537) Java 2 security failures - doPrivs needed to run with Java 2 security mgr
[
https://issues.apache.org/jira/browse/CXF-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16221129#comment-16221129
]
ASF GitHub Bot commented on CXF-7537:
-
andymc12 commented on issue #326: [CXF-7537] Use doPriv when calling methods
needing Java 2 permissions - 3.1.X
URL: https://github.com/apache/cxf/pull/326#issuecomment-339785475
I must've mixes streams here... I'm planning to close this PR and resubmit
the doPriv changes from PR #325 into the 3.1.X stream directly.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Java 2 security failures - doPrivs needed to run with Java 2 security mgr
> -
>
> Key: CXF-7537
> URL: https://issues.apache.org/jira/browse/CXF-7537
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.11, 3.2.0
>Reporter: Andy McCright
>
> While doing some Java 2 security testing, I found the following stacks that
> should be wrapped in doPriv blocks:
> Caused by: java.security.AccessControlException: Access denied
> ("java.util.PropertyPermission"
> "org.apache.cxf.io.CachedOutputStream.MaxSize" "read")
> at java.security.AccessController.throwACE(AccessController.java:157)
> at
> java.security.AccessController.checkPermissionHelper(AccessController.java:217)
> at
> java.security.AccessController.checkPermission(AccessController.java:349)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
> at
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> at java.lang.System.getProperty(System.java:443)
> at
> org.apache.cxf.io.CachedOutputStream.setDefaultMaxSize(CachedOutputStream.java:572)
> at
> org.apache.cxf.io.CachedOutputStream.(CachedOutputStream.java:70)
> java.security.AccessControlException: Access denied
> ("java.lang.RuntimePermission" "accessDeclaredMembers")
> at java.security.AccessController.throwACE(AccessController.java:157)
> at
> java.security.AccessController.checkPermissionHelper(AccessController.java:217)
> at
> java.security.AccessController.checkPermission(AccessController.java:349)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
> at java.lang.Class.checkMemberAccess(Class.java:200)
> at java.lang.Class.getDeclaredMethods(Class.java:992)
> at
> org.apache.cxf.jaxrs.utils.ResourceUtils.findPreDestroyMethod(ResourceUtils.java:186)
> at
> org.apache.cxf.jaxrs.utils.ResourceUtils.findPreDestroyMethod(ResourceUtils.java:179)
> at
> org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.(PerRequestResourceProvider.java:63)
> Caused by: java.lang.RuntimeException: java.security.AccessControlException:
> Access denied ("java.net.SocketPermission" "127.0.0.1:8010" "connect,resolve")
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1503)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1489)
> at
> sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:3034)
> at
> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:500)
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:370)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1586)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1615)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1559)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
> ... 47 more
> More may be exposed after resolving these...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222585#comment-16222585
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147446613
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
Was puzzled to have this as well but there is no lifecycle hook to call the
destroy /dispose :(
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222565#comment-16222565
]
ASF GitHub Bot commented on CXF-7501:
-
reta opened a new pull request #329: CXF-7501: Cannot inject field in
ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329
Adding the new extension-based customization (`ServerConfigurableFactory`)
in order to control the way how providers are created and registered using
`FeatureContext::register` methods family. It allows to use proper mechanisms
in case of managed runtimes (like CDIs f.e.).
@sberyozkin @johnament Submitting through PR to have some feedback guys you
may have. The change is not really complex but touches a bit some internals.
Thanks.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it injects the fields annotated as *@Context* , not the fields
> annotated with *@Inject*.
> {code:java}
> for (ProviderInfo filter : containerFilters) {
> try {
> InjectionUtils.injectContexts(filter.getProvider(),
> filter, m);
> filter.getProvider().filter(context);
> } catch (IOException ex) {
> throw ExceptionUtils.toInternalServerErrorException(ex,
> null);
> }
> {code}
> It causes our filter(*JaxRsContextFilter*) to throw a NullPointerException
> when filtering the request because it uses the producer to perform some
> actions in this operation.
> I believe this field should be injected as well, not only the *@Context*
> fields.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222574#comment-16222574
]
ASF GitHub Bot commented on CXF-7501:
-
johnament commented on a change in pull request #329: CXF-7501: Cannot inject
field in ContainerRequestFilter (and generally, into any providers registered
using FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147445943
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
I see we have a create... should we also have a destroy? Otherwise, in CDI,
you run the risk of having dependent scoped beans lying around. I'm not sure
if these are meant to be per-request objects or global objects, but if they are
per request and `@Dependent` scoped then you'll want to destroy them.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
>
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222636#comment-16222636
]
ASF GitHub Bot commented on CXF-7501:
-
rmannibucau commented on a change in pull request #329: CXF-7501: Cannot inject
field in ContainerRequestFilter (and generally, into any providers registered
using FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147456626
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
the client has close() so we can - worse case - use that. Also if the
beanManager.isNormalScope(bean.getScope()) is true we don't need to call
context.release()
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222704#comment-16222704
]
ASF GitHub Bot commented on CXF-7501:
-
rmannibucau commented on a change in pull request #329: CXF-7501: Cannot inject
field in ContainerRequestFilter (and generally, into any providers registered
using FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147467401
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
-> bam :)
the server has it too (destroy() from memory)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222683#comment-16222683
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147464372
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
This is server-side ... :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it injects the fields annotated as *@Context* ,
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222705#comment-16222705
]
ASF GitHub Bot commented on CXF-7501:
-
rmannibucau commented on a change in pull request #329: CXF-7501: Cannot inject
field in ContainerRequestFilter (and generally, into any providers registered
using FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147467401
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
-> bam :)
the server has it too (destroy() from memory), that said it is true for a
client in a server ;)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222725#comment-16222725
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147470304
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
@rmannibucau let me try to figure out if we could hook in there, thanks for
the hint
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222771#comment-16222771
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147511834
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
@johnament @rmannibucau Haven't found the acceptable way to dispose the
created beans. It would be good to have that however `Feature`s (and
`DynamicFeature`s) are instantiated at deployment (when JAX-RS resources are
discovered) hereby should not be subject of request scoped but only global one.
When server is shutting down (destroy) everything will be gone so may not worth
introducing complex disposal mechanisms. Makes sense?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223083#comment-16223083
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147539875
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
Hard to disagree with that indeed, CXF should be a good citizen there. So
I've came up with quite simple solution using CDI events. Whenever we create
the context in such circumstances, we register it for later disposal inside
`JAXRSCdiResourceExtension` by firing the event (the same way we manage all
other managed beans we create inside the CDI extension). It seems to work
perfectly fine and releases the contexts on shutdown. Thoughts?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
>
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223302#comment-16223302
]
ASF GitHub Bot commented on CXF-7501:
-
rmannibucau commented on a change in pull request #329: CXF-7501: Cannot inject
field in ContainerRequestFilter (and generally, into any providers registered
using FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147548597
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
Looks good for the server side :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it injects the fields annotated as
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223478#comment-16223478
]
ASF GitHub Bot commented on CXF-7501:
-
reta closed pull request #329: CXF-7501: Cannot inject field in
ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
new file mode 100644
index 000..15d4643d847
--- /dev/null
+++
b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
@@ -0,0 +1,91 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.cdi.event.DisposableCreationalContext;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
+final AnnotatedType annotatedType =
beanManager.createAnnotatedType(cls);
+final InjectionTargetFactory injectionTargetFactory =
+beanManager.getInjectionTargetFactory(annotatedType);
+final BeanAttributes attributes =
beanManager.createBeanAttributes(annotatedType);
+final Bean bean = beanManager.createBean(attributes, cls,
injectionTargetFactory);
+final CreationalContext context =
beanManager.createCreationalContext(bean);
+
+if (!beanManager.isNormalScope(bean.getScope())) {
+beanManager.fireEvent(new
DisposableCreationalContext(context));
+}
+
+return beanManager.getReference(bean, cls, context);
+}
+}
+
+private static class CdiServerFeatureContextConfigurable extends
ConfigurableImpl {
+private final Instantiator instantiator;
+
+CdiServerFeatureContextConfigurable(FeatureContext mc, BeanManager
beanManager) {
+super(mc, RuntimeType.SERVER, SERVER_FILTER_INTERCEPTOR_CLASSES);
+this.instantiator = new CdiInstantiator(beanManager);
+}
+
+@Override
+protected Instantiator getInstantiator() {
+return instantiator;
+}
+}
+}
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
[jira] [Commented] (CXF-7501) Cannot inject field in ContainerRequestFilter
[
https://issues.apache.org/jira/browse/CXF-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223477#comment-16223477
]
ASF GitHub Bot commented on CXF-7501:
-
reta commented on a change in pull request #329: CXF-7501: Cannot inject field
in ContainerRequestFilter (and generally, into any providers registered using
FeatureContext)
URL: https://github.com/apache/cxf/pull/329#discussion_r147553761
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/CdiServerConfigurableFactory.java
##
@@ -0,0 +1,85 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.AnnotatedType;
+import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.BeanAttributes;
+import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.InjectionTargetFactory;
+import javax.ws.rs.RuntimeType;
+import javax.ws.rs.core.Configurable;
+import javax.ws.rs.core.FeatureContext;
+
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl;
+import org.apache.cxf.jaxrs.impl.ConfigurableImpl.Instantiator;
+import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
+
+/**
+ * Creates the instance of Configurable suitable for CDI-managed runtime.
+ */
+public class CdiServerConfigurableFactory implements ServerConfigurableFactory
{
+private final BeanManager beanManager;
+
+CdiServerConfigurableFactory(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Configurable create(FeatureContext context) {
+return new CdiServerFeatureContextConfigurable(context, beanManager);
+}
+
+/**
+ * Instantiates the instance of the provider using CDI/BeanManager
+ */
+private static class CdiInstantiator implements Instantiator {
+private final BeanManager beanManager;
+
+CdiInstantiator(final BeanManager beanManager) {
+this.beanManager = beanManager;
+}
+
+@Override
+public Object create(Class cls) {
Review comment:
Thanks guys for the comments, merging ...
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot inject field in ContainerRequestFilter
> -
>
> Key: CXF-7501
> URL: https://issues.apache.org/jira/browse/CXF-7501
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10, 3.2.0
> Environment: Linux Mint 64 bit, TomEE Plus 7.0.3, JavaEE 7
> application using MVC specification and reference implementation(Libs
> Attached)
>Reporter: Jeyvison Nascimento
>Assignee: Andriy Redko
> Labels: cdi
> Attachments: javax-mvc.jar, ozark.jar
>
>
> Hey folks.
> We found a weird behavior while running MVC specification(JSR 371) on TomEE
> witch CXF. We have a *ContainerRequestFilter* defined called
> *JaxRsContextFilter*
> {code:java}
> @PreMatching
> @Priority(0)
> public class JaxRsContextFilter implements ContainerRequestFilter {
> @Inject
> private JaxRsContextProducer jaxRsContextProducer;
> @Context
> private Configuration configuration;
> @Context
> private HttpServletRequest request;
> @Context
> private HttpServletResponse response;
> public JaxRsContextFilter() {
> }
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> this.jaxRsContextProducer.populate(this.configuration, this.request,
> this.response);
> }
> }
> {code}
> You can see that we have a JaxRsContextProducer annotated to be injected as a
> field in our object but when JAXRSUtils is called to run the the container
> filters it injects the fields annotated as
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306856#comment-16306856
]
ASF GitHub Bot commented on CXF-7571:
-
johnament commented on a change in pull request #351: [CXF-7571] Adding support
for CDI injection of @Context objects.
URL: https://github.com/apache/cxf/pull/351#discussion_r159124524
##
File path:
systests/cdi/base/src/main/java/org/apache/cxf/systests/cdi/base/BookStoreVersion.java
##
@@ -22,20 +22,25 @@
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.ws.rs.GET;
-import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
+import org.apache.cxf.systests.cdi.base.context.CustomContext;
+
@RequestScoped
public class BookStoreVersion {
@Inject
private String version;
-@Context
+@Inject
private HttpHeaders httpHeaders;
+@Inject
Review comment:
@reta yes, that's what I'm expecting to happen, however I'm never seeing the
bean invoked for this context object.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307029#comment-16307029
]
ASF GitHub Bot commented on CXF-7571:
-
reta commented on a change in pull request #351: [CXF-7571] Adding support for
CDI injection of @Context objects.
URL: https://github.com/apache/cxf/pull/351#discussion_r159132277
##
File path:
systests/cdi/base/src/main/java/org/apache/cxf/systests/cdi/base/BookStoreVersion.java
##
@@ -22,20 +22,25 @@
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.ws.rs.GET;
-import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
+import org.apache.cxf.systests.cdi.base.context.CustomContext;
+
@RequestScoped
public class BookStoreVersion {
@Inject
private String version;
-@Context
+@Inject
private HttpHeaders httpHeaders;
+@Inject
Review comment:
@johnament I conducted a short debug session, it looks like it is working as
expected / described, I see `DelegateContextAnnotatedType`,
`ContextProducerBean` and finally `CustomContextImpl` being invoked in case
when `CustomContext` is annotated with `@Context` annotation. Interesting, what
is happening in your case ...
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306434#comment-16306434
]
ASF GitHub Bot commented on CXF-7571:
-
reta commented on a change in pull request #351: [CXF-7571] Adding support for
CDI injection of @Context objects.
URL: https://github.com/apache/cxf/pull/351#discussion_r159089178
##
File path:
systests/cdi/base/src/main/java/org/apache/cxf/systests/cdi/base/BookStoreVersion.java
##
@@ -22,20 +22,25 @@
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.ws.rs.GET;
-import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
+import org.apache.cxf.systests.cdi.base.context.CustomContext;
+
@RequestScoped
public class BookStoreVersion {
@Inject
private String version;
-@Context
+@Inject
private HttpHeaders httpHeaders;
+@Inject
Review comment:
@johnament Not sure I understood the exact nature of the problem, but with
`@Context` annotation the `CustomContext` is being processed by
`DelegateContextAnnotatedType` which injects into it the proxy value (CDI
managed one), and later on the instance is created by `ContextProducerBean` on
first invocation. Is it something along this lines or absolutely different
flow?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7604) Change to "Error occurred during error handling, give up!" message
[ https://issues.apache.org/jira/browse/CXF-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314006#comment-16314006 ] ASF GitHub Bot commented on CXF-7604: - andymc12 opened a new pull request #364: CXF-7604 Refine error message during error handling URL: https://github.com/apache/cxf/pull/364 Use Messages.properties and change message to better indicate that an error occurred during error handling, preventing further action. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change to "Error occurred during error handling, give up!" message > -- > > Key: CXF-7604 > URL: https://issues.apache.org/jira/browse/CXF-7604 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.14, 3.2.1 >Reporter: Andy McCright >Priority: Minor > > One of our users complained about the message "Error occurred during error > handling, give up!" that is output from AbstractFaultChainInitiatorObserver. > The complaint is that it sounds like the message is telling the user to give > up, rather than alerting them that error handling process is aborting due to > an unexpected failure. > It looks like that message is hardcoded into the Java source instead of > loaded from the Messages.properties file, so this should probably change to. > I'd like to suggest that we change the message to something like this: > _An unexpected error occurred during error handling. No further error > processing will occur._ > Please comment if you have strong opinions on the proposed wording or have > other suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16300716#comment-16300716
]
ASF GitHub Bot commented on CXF-7571:
-
johnament commented on issue #351: [CXF-7571] Adding support for CDI injection
of @Context objects.
URL: https://github.com/apache/cxf/pull/351#issuecomment-353482392
Ok, that makes me feel better. there is one that doesn't have an interface,
so it will be an issue: `OAuthContext`. But we could just skip it for now.
Here's something that is a possible issue. `UserInfoContext` extends
`IdTokenContext`, so you could end up with ambiguous dependencies (but may not
if i only register one type).
So I probably wasn't too far off, just off by 1.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7598) Log warning mentions deleted class
[
https://issues.apache.org/jira/browse/CXF-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302843#comment-16302843
]
ASF GitHub Bot commented on CXF-7598:
-
deki closed pull request #361: [CXF-7598] Update warning log
URL: https://github.com/apache/cxf/pull/361
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
index f1ef9da0193..a9cace5711e 100644
---
a/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
+++
b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
@@ -442,7 +442,7 @@ private void checkActions(
if (signatureParts != null) {
String warning = "To enforce that particular elements were signed
you must either "
+ "use WS-SecurityPolicy, or else use the
CryptoCoverageChecker or "
-+ "SignatureCoverageChecker";
++ "DefaultCryptoCoverageChecker";
LOG.warning(warning);
}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Log warning mentions deleted class
> --
>
> Key: CXF-7598
> URL: https://issues.apache.org/jira/browse/CXF-7598
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.6.1, 2.6.2, 2.4.10, 2.6.3, 2.7, 2.6.4, 2.7.1, 2.6.5,
> 2.7.2, 2.6.6, 2.7.3, 2.7.4, 2.6.7, 2.6.8, 2.7.5, 2.5.11, 2.6.9, 2.7.6,
> 2.6.10, 2.7.7, 2.7.8, 2.6.11, 2.6.12, 2.7.9, 2.6.13, 2.7.10, 2.7.11, 2.6.14,
> 3.0, 2.6.15, 2.7.12, 3.0.1, 2.7.13, 3.0.2, 2.6.16, 3.0.3, 2.7.14, 3.0.4,
> 2.7.15, 3.1, 2.7.16, 3.0.5, 3.1.1, 3.0.6, 2.7.17, 3.1.2, 3.1.3, 2.7.18,
> 3.0.7, 3.1.4, 3.1.5, 3.0.8, 3.1.6, 3.0.9, 3.0.10, 3.1.7, 3.1.8, 3.1.9,
> 3.0.12, 3.1.10, 3.0.13, 3.1.11, 3.1.12, 3.0.14, 3.0.15, 3.1.13, 3.2.0,
> 3.0.16, 3.1.14, 3.2.1
>Reporter: Juan Moreno
>Priority: Trivial
> Labels: runtime, security
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> The WSS4JInInterceptor class mentions in warning log to deleted class
> SignatureCoverageChecker (line 445). This class was deleted in commit
> [a3ed48dcbaf4d0741637771de2d34888e473ab0e|https://github.com/apache/cxf/commit/a3ed48dcbaf4d0741637771de2d34888e473ab0e]
> and replaced by DefaultCryptoCoverageChecker. The log should be mention to
> DefaultCryptoCoverageChecker.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7604) Change to "Error occurred during error handling, give up!" message
[
https://issues.apache.org/jira/browse/CXF-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317008#comment-16317008
]
ASF GitHub Bot commented on CXF-7604:
-
andymc12 closed pull request #364: CXF-7604 Refine error message during error
handling
URL: https://github.com/apache/cxf/pull/364
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
b/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
index 629de73325e..670b73e156b 100644
---
a/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
+++
b/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
@@ -111,10 +111,10 @@ public void onMessage(Message message) {
try {
chain.doIntercept(faultMessage);
} catch (RuntimeException exc) {
-LOG.log(Level.SEVERE, "Error occurred during error handling,
give up!", exc);
+LOG.log(Level.SEVERE, "ERROR_DURING_ERROR_PROCESSING", exc);
throw exc;
} catch (Exception exc) {
-LOG.log(Level.SEVERE, "Error occurred during error handling,
give up!", exc);
+LOG.log(Level.SEVERE, "ERROR_DURING_ERROR_PROCESSING", exc);
throw new RuntimeException(exc);
}
} finally {
diff --git a/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
b/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
index a0f7b15212a..487243982f2 100644
--- a/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
+++ b/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
@@ -42,4 +42,5 @@ EXCEPTION_WHILE_WRITING_FAULT = Exception occurred while
writing fault.
EXCEPTION_WHILE_CREATING_EXCEPTION = Exception occurred while creating
exception: {0}
UNEXPECTED_WRAPPER_ELEMENT = Unexpected wrapper element {0} found. Expected
{1}.
UNEXPECTED_ELEMENT = Unexpected element {0} found. Expected {1}.
+ERROR_DURING_ERROR_PROCESSING=An unexpected error occurred during error
handling. No further error processing will occur.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change to "Error occurred during error handling, give up!" message
> --
>
> Key: CXF-7604
> URL: https://issues.apache.org/jira/browse/CXF-7604
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
>
> One of our users complained about the message "Error occurred during error
> handling, give up!" that is output from AbstractFaultChainInitiatorObserver.
> The complaint is that it sounds like the message is telling the user to give
> up, rather than alerting them that error handling process is aborting due to
> an unexpected failure.
> It looks like that message is hardcoded into the Java source instead of
> loaded from the Messages.properties file, so this should probably change to.
> I'd like to suggest that we change the message to something like this:
> _An unexpected error occurred during error handling. No further error
> processing will occur._
> Please comment if you have strong opinions on the proposed wording or have
> other suggestions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322130#comment-16322130 ] ASF GitHub Bot commented on CXF-7520: - ffang commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356919645 @jimma , looks good to me. Just one thing, as this is JDK9 specific, could you please add a java9 profile in pom.xml and put jaxb-impl dependency there? Also how about add a code to check the jdk version , if it's jdk9, set the NoEscapeHandler? Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322199#comment-16322199 ] ASF GitHub Bot commented on CXF-7520: - asoldano commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356934100 @ffang, do you think that's really needed? As long as there's no side effect when running on older jdks, I don't think we should be increasing the complexity of the build. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322202#comment-16322202 ] ASF GitHub Bot commented on CXF-7520: - asoldano commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356934100 @ffang, do you think that's really needed? As long as there's no side effect when running on older jdks, I don't think we should be increasing the complexity of the build. Similar reasoning for the NoEscapeHandler: @jimma , does the addition of that affect the execution with jdk 8? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322216#comment-16322216 ] ASF GitHub Bot commented on CXF-7520: - dkulp commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356937052 The deps are scope=provided so they shouldn't affect anyone downstream as they won't be pulled in. Thus, the profile is likely not needed. HOWEVER, there is an issue at runtime if the com.sun.xml.bind.marshaller.CharacterEscapeHandler class is not found (example: using in JDK version of jaxb instead of the jar), then the writer won't be createable at all and everything will fail. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322247#comment-16322247 ] ASF GitHub Bot commented on CXF-7520: - ffang commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356943373 java9 profile make the pom more organized, we know it's for java9 only, like a marker. I think it's important for us to clearly know which is java9 specific, can help us to resolve similar issue in the future, as we have some clear marker to draw upon. My 2 cents. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321896#comment-16321896 ] ASF GitHub Bot commented on CXF-7520: - jimma opened a new pull request #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[ https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322558#comment-16322558 ] ASF GitHub Bot commented on CXF-7520: - dkulp commented on issue #365: [CXF-7520]:Ensure CXF can build with JDK9 GA(build 9+181) URL: https://github.com/apache/cxf/pull/365#issuecomment-356992972 One more question: does this actually WORK?What happens if you try to send a < or a > character? Those need to be escaped. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ensure CXF can build with JDK9 GA(build 9+181) > -- > > Key: CXF-7520 > URL: https://issues.apache.org/jira/browse/CXF-7520 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.2 > > > a couple of cxf test failied with JDK9 GA due to recent change > Mainly in JAXB and SAAJ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7608) [brave feature] Propagate trace ids as it lets log correlation to be consistent even if not sampling
[
https://issues.apache.org/jira/browse/CXF-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326848#comment-16326848
]
ASF GitHub Bot commented on CXF-7608:
-
aldex32 commented on issue #367: [CXF-7608] Propagate trace ids as it lets log
correlation to be consi…
URL: https://github.com/apache/cxf/pull/367#issuecomment-357881668
Hi @reta , I tried to do an integration test in the test class you mentioned
above but didn't succeeded.
What I did is:
* Created a server with brave feature with sampling `NEVER_SAMPLER`
* Invoke one of `bookstore` API
* Then created a `POST_INVOKE` interceptor which would get the request
attribute `org.apache.cxf.tracing.brave.span` and check if the
`TraceScope#SpanInScope` is in `AbstractTracingProvider.TraceScopeHolder`.
The issue I faced is that I cannot cast
`((HttpServletRequest)message.get("HTTP.REQUEST")).getAttribute("org.apache.cxf.tracing.brave.span")`
to `TraceScopeHolder` since it is a protected and then I cannot assert on it.
Do you have any idea how should I test it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [brave feature] Propagate trace ids as it lets log correlation to be
> consistent even if not sampling
>
>
> Key: CXF-7608
> URL: https://issues.apache.org/jira/browse/CXF-7608
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Reporter: Aldo Sinanaj
>Priority: Major
>
> Currently the trace ids are not propagated and not reflected on log MDC
> metadata when it is not sampled. Seems that in
> {{AbstractBraveProvider.class}} and {{AbstractBraveClientProvider.class}}
> there is a condition which decides whether or not to do the "brave tracing".
> I had a chat with [~adriancole] and he suggested me to fix this condition by
> removing the check on {{span#isNoop}}, since it is not the provider
> responsibility I guess.
> I'm going to do a pull request on github.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325580#comment-16325580
]
ASF GitHub Bot commented on CXF-7571:
-
johnament commented on issue #351: [CXF-7571] Adding support for CDI injection
of @Context objects.
URL: https://github.com/apache/cxf/pull/351#issuecomment-357511714
@reta originally I wasn't going to do that, since its just a CDI feature.
But I updated the existing resources to demonstrate both constructor and field
injection.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325633#comment-16325633
]
ASF GitHub Bot commented on CXF-7571:
-
johnament closed pull request #351: [CXF-7571] Adding support for CDI injection
of @Context objects.
URL: https://github.com/apache/cxf/pull/351
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/AbstractCXFBean.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/AbstractCXFBean.java
index dea25bfa354..687f3a8c864 100644
--- a/integration/cdi/src/main/java/org/apache/cxf/cdi/AbstractCXFBean.java
+++ b/integration/cdi/src/main/java/org/apache/cxf/cdi/AbstractCXFBean.java
@@ -25,21 +25,21 @@
import java.util.Set;
import javax.enterprise.context.ApplicationScoped;
+import javax.enterprise.context.spi.CreationalContext;
import javax.enterprise.inject.Any;
import javax.enterprise.inject.Default;
import javax.enterprise.inject.spi.Bean;
+import javax.enterprise.inject.spi.InjectionPoint;
import javax.enterprise.util.AnnotationLiteral;
abstract class AbstractCXFBean implements Bean {
+static final Any ANY = new AnyLiteral();
+static final Default DEFAULT = new DefaultLiteral();
@Override
public Set getQualifiers() {
Set qualifiers = new HashSet<>();
-qualifiers.add(new AnnotationLiteral() {
-private static final long serialVersionUID = 1L;
-});
-qualifiers.add(new AnnotationLiteral() {
-private static final long serialVersionUID = 1L;
-});
+qualifiers.add(ANY);
+qualifiers.add(DEFAULT);
return qualifiers;
}
@@ -65,8 +65,27 @@ public boolean isNullable() {
return false;
}
+@Override
+public Set getInjectionPoints() {
+return Collections.emptySet();
+}
+
+
+@Override
+public void destroy(T instance, CreationalContext creationalContext) {
+creationalContext.release();
+}
+
@Override
public Set< Class< ? extends Annotation > > getStereotypes() {
return Collections.emptySet();
}
+
+private static class DefaultLiteral extends AnnotationLiteral
implements Default {
+private static final long serialVersionUID = 1L;
+}
+
+private static class AnyLiteral extends AnnotationLiteral implements
Any {
+private static final long serialVersionUID = 1L;
+}
}
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
new file mode 100644
index 000..7fab97782d7
--- /dev/null
+++ b/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
@@ -0,0 +1,100 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.cdi;
+
+import java.lang.annotation.Annotation;
+import java.lang.reflect.ParameterizedType;
+import java.lang.reflect.Type;
+import java.util.HashSet;
+import java.util.Set;
+
+import javax.enterprise.context.RequestScoped;
+import javax.enterprise.context.spi.CreationalContext;
+import javax.enterprise.inject.spi.PassivationCapable;
+
+import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.message.Message;
+import org.apache.cxf.phase.PhaseInterceptorChain;
+
+public class ContextProducerBean extends AbstractCXFBean implements
PassivationCapable {
+private final Type type;
+
+ContextProducerBean(Type type) {
+this.type = type;
+}
+
+@Override
+public Set getQualifiers() {
+Set qualifiers = new HashSet<>(2);
+qualifiers.add(ContextResolved.LITERAL);
+qualifiers.add(DEFAULT);
+return qualifiers;
+}
+
+@Override
+public Class getScope() {
+return RequestScoped.class;
+}
+
+@Override
+public Class getBeanClass() {
+return (Class)type;
+}
+
+@Override
+
[jira] [Commented] (CXF-7571) Revamp of the CXF injection implementation
[
https://issues.apache.org/jira/browse/CXF-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325632#comment-16325632
]
ASF GitHub Bot commented on CXF-7571:
-
johnament commented on issue #351: [CXF-7571] Adding support for CDI injection
of @Context objects.
URL: https://github.com/apache/cxf/pull/351#issuecomment-357519951
I'll address any remaining issues in a separate PR. I'm still curious about
removing the current logic for providers, but can address that later.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Revamp of the CXF injection implementation
> ---
>
> Key: CXF-7571
> URL: https://issues.apache.org/jira/browse/CXF-7571
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: John D. Ament
>
> As more deep integration with CDI revealed, there are complexities in
> bringing together {{@Context}}- and {{@Inject}}-based injections.
> Encapsulating CXF injection implementation and than delegating the hard work
> to appropriate strategy (CDI, Spring, ...) would be the right solution to
> address the problem at its roots.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7520) Ensure CXF can build with JDK9 GA(build 9+181)
[
https://issues.apache.org/jira/browse/CXF-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16331790#comment-16331790
]
ASF GitHub Bot commented on CXF-7520:
-
jimma closed pull request #365: [CXF-7520]:Ensure CXF can build with JDK9
GA(build 9+181)
URL: https://github.com/apache/cxf/pull/365
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/core/src/main/java/org/apache/cxf/common/jaxb/EscapeHandlerInvocationHandler.java
b/core/src/main/java/org/apache/cxf/common/jaxb/EscapeHandlerInvocationHandler.java
new file mode 100644
index 000..64f1385ac46
--- /dev/null
+++
b/core/src/main/java/org/apache/cxf/common/jaxb/EscapeHandlerInvocationHandler.java
@@ -0,0 +1,45 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.common.jaxb;
+
+import java.io.Writer;
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.Method;
+
+public final class EscapeHandlerInvocationHandler implements InvocationHandler
{
+
+private Object target;
+public EscapeHandlerInvocationHandler(Object obj) {
+target = obj;
+}
+@Override
+public Object invoke(Object proxy, Method method, Object[] args) throws
Throwable {
+Object result = null;
+if (method.getName().equals("escape") && args.length == 5) {
+if ((Integer)args[1] == 0 && (Integer)args[2] == 0) {
+Writer writer = (Writer)args[4];
+writer.write("");
+return null;
+}
+result = method.invoke(target, args);
+}
+return result;
+}
+
+}
diff --git a/core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java
b/core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java
index e33a12188d5..685cb077d9f 100644
--- a/core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java
+++ b/core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java
@@ -30,6 +30,7 @@
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;
import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.lang.reflect.Type;
@@ -85,6 +86,7 @@
import org.apache.cxf.common.util.ASMHelper.Opcodes;
import org.apache.cxf.common.util.CachedClass;
import org.apache.cxf.common.util.PackageUtils;
+import org.apache.cxf.common.util.ProxyHelper;
import org.apache.cxf.common.util.ReflectionInvokationHandler;
import org.apache.cxf.common.util.ReflectionInvokationHandler.WrapReturn;
import org.apache.cxf.common.util.ReflectionUtil;
@@ -123,6 +125,7 @@
private static final Map BUILTIN_DATATYPES_MAP;
private static final Map HOLDER_TYPES_MAP;
private static ClassLoader jaxbXjcLoader;
+private static Object jaxbEscapeHandler;
static {
BUILTIN_DATATYPES_MAP = new HashMap<>();
@@ -1531,4 +1534,44 @@ public static JAXBBeanInfo getBeanInfo(JAXBContextProxy
context, Class cls) {
return ReflectionInvokationHandler.createProxyWrapper(o,
JAXBBeanInfo.class);
}
+public static void setMinimumEscapeHandler(Marshaller marshaller) {
+String postFix = "";
+if (marshaller.getClass().getName().contains("com.sun.xml.internal")
+|| marshaller.getClass().getName().contains("eclipse")) {
+//eclipse moxy accepts sun package CharacterEscapeHandler
+postFix = ".internal";
+} else if
(marshaller.getClass().getName().contains("com.sun.xml.bind")) {
+postFix = "";
+} else {
+LOG.log(Level.WARNING, "Failed to set MinumEscapeHandler for
unknown jaxb marshaller:"
+ + marshaller);
+return;
+}
+try {
+Class handlerClass = ClassLoaderUtils.loadClass("com.sun.xml" +
postFix
+
