[jira] [Resolved] (CXF-8091) Update Commons JEXL
[ https://issues.apache.org/jira/browse/CXF-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8091. -- Resolution: Fixed > Update Commons JEXL > --- > > Key: CXF-8091 > URL: https://issues.apache.org/jira/browse/CXF-8091 > Project: CXF > Issue Type: Improvement > Components: STS >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.4.0 > > > This task is to perform a major version upgrade of Commons JEXL in the STS > for 3.4.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
[ https://issues.apache.org/jira/browse/CXF-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8072. > Loggers logs request twice in case of Fault (CXF-7518 again) > > > Key: CXF-8072 > URL: https://issues.apache.org/jira/browse/CXF-8072 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.2.9 >Reporter: Tomasz Poręba >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.2.10, 3.3.3 > > > I noticed that I experience the same problem as in issue CXF-7518 but in far > newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same > code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8032) Adding LoggingFeature enables chunking response
[ https://issues.apache.org/jira/browse/CXF-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8032. > Adding LoggingFeature enables chunking response > --- > > Key: CXF-8032 > URL: https://issues.apache.org/jira/browse/CXF-8032 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.3.1 > Environment: OS - Windows 10 > Java - 1.8.0_181 > Tomcat - 8.5 > CXF - 3.3.1 >Reporter: karthic >Priority: Major > Labels: triaged > Fix For: 3.3.3 > > Time Spent: 20m > Remaining Estimate: 0h > > Adding org.apache.cxf.feature.LoggingFeature to Bus feature affects the > response header, it adds transfer encoding as chunked, where as without > LoggingFeature the content length is set and no transfer encoding set. > > > > Response header when LoggingFeature is added, > HTTP/1.1 200 > Content-Type: text/xml;charset=UTF-8 > Transfer-Encoding: chunked > Date: Wed, 01 May 2019 05:43:46 GMT > Response header when LoggingFeature is removed, > HTTP/1.1 200 > Content-Type: text/xml;charset=UTF-8 > Content-Length: 496 > Date: Wed, 01 May 2019 06:30:04 GMT > Possible issue may be because converting the original OutputStream to > CacheAndWriteOutputStream, I am not able look into further -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8063) Support lower logging level in Slf4jEventSender
[ https://issues.apache.org/jira/browse/CXF-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8063. > Support lower logging level in Slf4jEventSender > --- > > Key: CXF-8063 > URL: https://issues.apache.org/jira/browse/CXF-8063 > Project: CXF > Issue Type: Improvement > Components: logging >Reporter: Valentin Aitken >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.3.3 > > > When one uses LoggingFeature, by default it can only write to info log. > I would like to be able to log it as debug or trace. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8083) ensure java2swagger-plugin|java2ws-plugin m2e compatible
[
https://issues.apache.org/jira/browse/CXF-8083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8083.
> ensure java2swagger-plugin|java2ws-plugin m2e compatible
>
>
> Key: CXF-8083
> URL: https://issues.apache.org/jira/browse/CXF-8083
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
>
> avoid errors like
> {code}
> Plugin execution not covered by lifecycle configuration:
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8073) oauth2.provider.OAuthServiceException error message doesn't includes "error" field
[ https://issues.apache.org/jira/browse/CXF-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8073. > oauth2.provider.OAuthServiceException error message doesn't includes "error" > field > -- > > Key: CXF-8073 > URL: https://issues.apache.org/jira/browse/CXF-8073 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.1.15 >Reporter: Rodrigo Carvalho Silva >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.3.3, 3.4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When an oauth2.provider.OAuthServiceException is thrown, the error message > gives no clues about the actual error because the message doesn't includes > the "error" field. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8056) Update to latest Brave 5.6.5
[ https://issues.apache.org/jira/browse/CXF-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8056. > Update to latest Brave 5.6.5 > > > Key: CXF-8056 > URL: https://issues.apache.org/jira/browse/CXF-8056 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.2.9, 3.3.2 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > Update to latest Brave 5.6.5 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8068) Log any error in the SAML SSO component under warning
[ https://issues.apache.org/jira/browse/CXF-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8068. > Log any error in the SAML SSO component under warning > - > > Key: CXF-8068 > URL: https://issues.apache.org/jira/browse/CXF-8068 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.3 > > > The SAML SSO component currently logs validation errors under "info" - it > would be better to log them under "warning". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8052) Cannot set JAXB schema compiler options
[
https://issues.apache.org/jira/browse/CXF-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8052.
> Cannot set JAXB schema compiler options
> ---
>
> Key: CXF-8052
> URL: https://issues.apache.org/jira/browse/CXF-8052
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
>Affects Versions: 3.3.2
> Environment: OpenJDK 12
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Blocker
> Fix For: 3.2.10, 3.3.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JAXB generates an is-prefix getter for a boolean data type in my WSDL instead
> of a get-prefix getter, see
> [https://www.ibm.com/developerworks/community/blogs/Dougclectica/entry/JAXB_with_Java_7_and_xs_boolean?lang=en]
>
> The workaround is simple - pass the "-enableIntrospection" argument to the
> JAXB compiler. Unfortunately, CXF fails with this error -
> {quote}Caused by: com.sun.tools.xjc.BadCommandLineException: grammar is not
> specified
> at com.sun.tools.xjc.Options.parseArguments(Options.java:861)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
> {quote}
>
> The test code to reproduce this is very simple -
> {quote}JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> String[] schemaCompilerOptions = new String[] \{"-enableIntrospection"};
> factory.setSchemaCompilerOptions(schemaCompilerOptions);
> Client client = factory.createClient();
> {quote}
>
> The error occurs in
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createSchemaCompiler
> {quote}if (schemaCompilerOptions != null && schemaCompilerOptions.length > 0)
> {
> compiler.getOptions().parseArguments(schemaCompilerOptions);
> }
> {quote}
>
> parseArguments expects the XML Schemas to have already been added to the
> compiler.getOptions() object, but in DynamicClientFactory, the schemas are
> added after parseArguments is called, which is why parseArguments spits out
> the "grammar is not specified" error.
> This can be fixed in a couple of ways -
> # Add a dummy schema to the compiler.getOptions() object before invoking
> parseArguments on it.
> # Relocate the call to parseArguments after the schemas have been added to
> the compiler.getOptions() object.
>
> Option 1 is used by
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding in its
> initialize() method -
> {quote}// keep parseArguments happy, supply dummy required command-line opts
> opts.addGrammar(new InputSource("null"));
> opts.parseArguments(args.toArray(new String[0]));
> {quote}
>
> Personally, I prefer relocating the call instead of adding a dummy schema.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8043) XKMS LdapCertificateRepo searching using DN doesn't work
[ https://issues.apache.org/jira/browse/CXF-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8043. > XKMS LdapCertificateRepo searching using DN doesn't work > > > Key: CXF-8043 > URL: https://issues.apache.org/jira/browse/CXF-8043 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.9, 3.3.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > XKMS LdapCertificateRepo searching using DN doesn't work. It finds the cert > successfully, but then goes on to try to find by UID and returns the result > of this operation, meaning that the first result is discarded. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8041) Error resolving relative XSD Schema on Tomcat
[
https://issues.apache.org/jira/browse/CXF-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8041.
> Error resolving relative XSD Schema on Tomcat
> -
>
> Key: CXF-8041
> URL: https://issues.apache.org/jira/browse/CXF-8041
> Project: CXF
> Issue Type: Bug
> Components: Core, Transports
>Affects Versions: 3.3.1
>Reporter: Mike M.
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
> Attachments: cxf-tomcat-resource-resolver.zip
>
>
> We found an issue in a CXF JAX-WS project when running in WSDL-first mode
> with schema-validation enabled on Tomcat. The WSDL references an external XSD
> schema using a relative path. The WSDL and XSD are bundled with the
> application and are present on the classpath.
> *Expectation:*
> The XSD should be resolved successfully and schema validation should work.
> *Actual behavior:*
> * The resource lookup runs through CXF {{EndpointReferenceUtils}}'
> {{SchemaLSResourceResolver}}. This one runs through multiple strategies for
> resolving the imported XSD URL to a resource. One of them (currently around
> line 150) is an attempt to ask a {{ResourceManager}} for the URL.
> * In a Servlet context, this will be handled by CXF's
> {{ServletContextResourceResolver}}. This one (currently starting around line
> 82) will ask the actual {{ServletContext}} for the URL. While doing so, it
> will catch and ignore {{MalformedURLException}} s as documented in the
> {{ServletContext}} interface as well as {{URISyntaxException}} s (probably
> precautionary).
> * Entering Tomcat's implementation: the call will go through Tomcat's
> {{ApplicationContext}} and end up in the {{StandardRoot}}'s
> {{#validate(String)}} method. Unfortunately, while validating the provided
> URL, this one throws {{IllegalArgumentException}} s instead of just returning
> {{null}}. In our case, since we resolve the XSD schema relative to the WSDL
> and need to go up some levels (../../) from it, Tomcat thinks we're trying to
> escape the application context and will trigger the
> {{IllegalArgumentException}}.
> * Unfortunately though, this exception never gets caught and propagates up
> the stack back to CXF's {{SchemaLSResourceResolver#resolveResource}}. This
> method had several strategies for resolving resources, remember? The annoying
> part is: we didn't even need that particular ServletContext strategy for our
> XSD, and one of the other methods (classpath lookup) would have resolved the
> XSD just fine, *had the ServletContext lookup not thrown the
> {{IllegalArgumentException}}*. That uncaught exception however, breaks the
> lookup entirely.
> *Solution proposal:*
> I think the least invasive solution would be for
> {{ServletContextResourceResolver}} to additionally catch
> {{IllegalArgumentException}} when calling {{ServletContext#getResource}}. It
> already catches {{URISyntaxException}} even though that one isn't documented
> by the {{ServletContext}} API. Catching an exception that basically says
> "Hey, this argument isn't valid" would be semantically similar imho.
> A more drastic approach would be catching all {{RuntimeException}} s from the
> Servlet Container in order to fulfill {{ResourceResolver#resolve}}'s
> contract, namely: "@return an instance of the resource or null if the
> resource cannot be resolved".
> *Reproducing the error:*
> I attached a sample project to this ticket that reproduces the issue. Make
> sure to follow the instructions in its README.md.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8021) Upgrade to OpenTracing 0.33
[ https://issues.apache.org/jira/browse/CXF-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8021. > Upgrade to OpenTracing 0.33 > --- > > Key: CXF-8021 > URL: https://issues.apache.org/jira/browse/CXF-8021 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.3.1 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.3.3 > > > https://github.com/opentracing/opentracing-java/releases/tag/0.33.0 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8071) XKMS LdapCertificateRepo searching using Service UID doesn't work
[ https://issues.apache.org/jira/browse/CXF-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8071. > XKMS LdapCertificateRepo searching using Service UID doesn't work > - > > Key: CXF-8071 > URL: https://issues.apache.org/jira/browse/CXF-8071 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.9, 3.3.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.2.10, 3.3.3 > > Time Spent: 20m > Remaining Estimate: 0h > > XKMS LdapCertificateRepo searching using Service UID doesn't work as > explained on the dev list: > https://lists.apache.org/thread.html/ad58b23cfc76ab678208196621446e961787339d41493f878b056486@%3Cdev.cxf.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8055) AsyncHTTPConduit should also consider jaxws spec timeout properties
[ https://issues.apache.org/jira/browse/CXF-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8055. > AsyncHTTPConduit should also consider jaxws spec timeout properties > --- > > Key: CXF-8055 > URL: https://issues.apache.org/jira/browse/CXF-8055 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > like > "javax.xml.ws.client.connectionTimeout" > "javax.xml.ws.client.receiveTimeout" -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8066) Support Doclet API (JDK13+)
[
https://issues.apache.org/jira/browse/CXF-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8066.
> Support Doclet API (JDK13+)
> ---
>
> Key: CXF-8066
> URL: https://issues.apache.org/jira/browse/CXF-8066
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.3.2
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.3.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The com.sun.javadoc.* API is gone in JDK 13 and is replaced with Doclet API.
> As such, the CXF builds are started to fail on JDK13 for
> {noformat}
> cxf-java2wadl-plugin{noformat}
> Example:
> {noformat}
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project cxf-java2wadl-plugin: Fatal error compiling:
> CompilerException: NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :cxf-java2wadl-plugin{noformat}
> (by adding the true to
> maven-compiler-plugin it is possible to get the clear error).
> The official migration guide:
> [https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration|https://download.java.net/java/early_access/jdk13/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration).]
> We may need to introduce the multi-release JAR since the Java 8/9/10/11 and
> 13+ implementation are not compatible.
> Related projects / issues:
> * maven-javadoc-plugin (is still using the old API):
> [https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master]
> * [https://bugs.openjdk.java.net/browse/JDK-8215608]
> * [https://bugs.openjdk.java.net/browse/JDK-8199325]
> * [https://jdk.java.net/13/release-notes]
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 4xx
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8062.
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 4xx
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG,
> cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8042) doPrivileged block doesn't totally work in ProxyClassLoaderCache
[
https://issues.apache.org/jira/browse/CXF-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8042.
> doPrivileged block doesn't totally work in ProxyClassLoaderCache
>
>
> Key: CXF-8042
> URL: https://issues.apache.org/jira/browse/CXF-8042
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.3.2
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 3.3.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ProxyClassLoaderCache logs the classloader with
> "currentInterface.getClassLoader()". This should use
> getClassLoader(currentInterface) under a doPrivileged block.
> {code:java}
> private ClassLoader createProxyClassLoader(Class proxyInterface) {
>
> for (Class currentInterface : PROXY_INTERFACES.get()) {
> ret.addLoader(getClassLoader(currentInterface));
> LOG.log(Level.FINE, "interface for new created ProxyClassLoader
> is "
> + currentInterface.getName());
> LOG.log(Level.FINE, "interface's classloader for new created
> ProxyClassLoader is "
> + currentInterface.getClassLoader());
> }
> return ret;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8051) Request gets corrupted when calling a stateful streamed secure conversation
[ https://issues.apache.org/jira/browse/CXF-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8051. > Request gets corrupted when calling a stateful streamed secure conversation > --- > > Key: CXF-8051 > URL: https://issues.apache.org/jira/browse/CXF-8051 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.3.2 > Environment: The request is running in a console application hosted > in Netbeans on Windows Server 2012 R2. The service is a .NET WCF service on > Windows Server 2012 R2. >Reporter: Henning Normann >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.3 > > Attachments: EcBad.txt, EcGood.txt, > ResponseFromSecurityTokenService.txt > > Time Spent: 20m > Remaining Estimate: 0h > > The request to a streamed secure conversation web service gets corrupted if > the service (.NET WCF) is configured as stateless (with a stateful token > carrying the state in soap cookies). If the service as configured as stateful > (no soap cookies), the request is valid. > Updated 2nd time: When the request is streamed, CXF doesn't stream the > payload of the content of the token cookie, and the reference from the cookie > is "unresolved". When the request is not-streamed, the cookie payload is > included as base64 inside the cookie element, and everything works fine. The > attached formatted requests EcBad.txt (failing from CXF) and EcGood.txt > (valid request from a .NET WCF client) show the issue. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8044) Setting compiler-fork to true is causing problems with Dynamic client
[ https://issues.apache.org/jira/browse/CXF-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8044. > Setting compiler-fork to true is causing problems with Dynamic client > - > > Key: CXF-8044 > URL: https://issues.apache.org/jira/browse/CXF-8044 > Project: CXF > Issue Type: Bug > Components: Simple Frontend >Affects Versions: 3.3.2 >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.3.3 > > > The simple frontend's DynamicClient, when it detects it is running on Java9+, > sets the system property org.apache.cxf.common.util.Compiler-fork to true. > This causes a variety of problems on Java 11 systems, in particularly on > Windows. There should be no need to set that and there isn't a way currently > to NOT set it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8077) WSS4JInInterceptor is not thread safe
[
https://issues.apache.org/jira/browse/CXF-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8077.
> WSS4JInInterceptor is not thread safe
> -
>
> Key: CXF-8077
> URL: https://issues.apache.org/jira/browse/CXF-8077
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.3.2
>Reporter: Shumin Li
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.1.18, 3.2.10, 3.3.3
>
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor uses a cached property
> WSSecurityEngine secEngineOverride. In the situation that the same instance
> of secEngineOverride is used for 2 or more threads, Following code in
> handleMessageInternal() will cause WSS4J to lookup wrong XML document.
> if (soapBody != null) {
> engine.setCallbackLookup(new CXFCallbackLookup(soapBody.getOwnerDocument(),
> soapBody));
> }
> In my case, interceptor is used to do X.509 authentication with Signature for
> signing. When 2 or more requests comes at the almost the same time, it
> produces following error for victim thread(s).
> org.apache.cxf.binding.soap.SoapFault: A security error was encountered when
> verifying the message
> at
> org.apache.cxf.ws.security.wss4j.WSS4JUtils.createSoapFault(WSS4JUtils.java:234)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:376)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:212)
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:92)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.boot.actuate.web.trace.servlet.HttpTraceFilter.doFilterInternal(HttpTraceFilter.java:88)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:209)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:178)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:357)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:270)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:109)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(Once
[jira] [Closed] (CXF-7966) Beanspector throws IllegalArgumentException when dealing with overridden methods
[
https://issues.apache.org/jira/browse/CXF-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-7966.
> Beanspector throws IllegalArgumentException when dealing with overridden
> methods
>
>
> Key: CXF-7966
> URL: https://issues.apache.org/jira/browse/CXF-7966
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 3.2.9, 3.3.2
>Reporter: matteo rulli
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Let's consider the following pojos:
> {code:java}
> public class A {
> private String value;
> public String getValue()\{ ... }
> public void setValue(String value) \{ ... }
> }
> public class B {
>
> private A aValue;
> public A getAValue()\{ ... }
> public void setAValue(A avalue) \{ ... }
> }
> {code}
> And assume one extends these pojos and decorates them with JPA annotations.
> To leverage CXF org.apache.cxf.jaxrs.ext.search.SearchContext and
> JPACriteriaQueryVisitor as explained in the docs
> ([http://cxf.apache.org/docs/jax-rs-search.html#JAX-RSSearch-JPA2.0]) and
> perform searches like
> {code:java}
> _s=aValue==*search token* {code}
> in OpenJPA one has to override the EntityB.getAValue as follows:
> {code:java}
> @Entity
> // ... other JPA annotations are omitted
> public class EntityB extends B {
>
> @Override
> // We need to specialize return type to EntityA to make SearchContext
> work
> public EntityA getAValue()\{ ... }
> // This method definition is needed to avoid java.lang.VerifyError
> from JPA provider
> public void setAValue(EntityA avalue) \{ ... }
> }
> {code}
> But with this scenario, the current implementation of
> org.apache.cxf.jaxrs.ext.search.Beanspector fails, throwing
> IllegalArgumentException: Accessor 'aValue' type mismatch, getter type is X
> while setter type is Y, X and Y depending on the order of the EntityB's
> methods as returned by the Class.getMethods().
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8076) Check for recursive calls when invoking on an STS using its own IssuedToken policy
[ https://issues.apache.org/jira/browse/CXF-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8076. > Check for recursive calls when invoking on an STS using its own IssuedToken > policy > -- > > Key: CXF-8076 > URL: https://issues.apache.org/jira/browse/CXF-8076 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > Check that we are not invoking on the STS using its own IssuedToken policy - > in which case we will end up with a recursive loop. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8080) MP Rest Client CompletionStages from async methods are never completed
[ https://issues.apache.org/jira/browse/CXF-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8080. > MP Rest Client CompletionStages from async methods are never completed > -- > > Key: CXF-8080 > URL: https://issues.apache.org/jira/browse/CXF-8080 > Project: CXF > Issue Type: Bug >Affects Versions: 3.3.2 >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.3.3 > > Time Spent: 20m > Remaining Estimate: 0h > > [Manish Kumar|https://twitter.com/manish2aug] first reported this issue in a > [Twitter post|[https://twitter.com/manish2aug/status/118627593379842]] > and then opened issue > [208|https://github.com/eclipse/microprofile-rest-client/issues/208] on the > MP Rest Client spec page. > > He provided an example that shows that the CompletionStage never completes, > leaving his test case hung. See the example here: > [https://gist.github.com/manish2aug/b4133b9fbedc2175e15b303a0682b552] > > It should be possible to fix this with a change to the MPRestClientCallback. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8064) OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint
[ https://issues.apache.org/jira/browse/CXF-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8064. > OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint > --- > > Key: CXF-8064 > URL: https://issues.apache.org/jira/browse/CXF-8064 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > we should add another ContainerRequestFilter for OpenApiFeature, so the > swagger related request can be intercepted and won't go in camel router, like > what we've done for Swagger2Feature. > In V3, io.swagger.v3.jaxrs2.integration.resources.OpenApiResource.getOpenApi > should be used to fetch swagger(json|yaml) payload -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8059) @FormParam inside @BeanParam not working
[
https://issues.apache.org/jira/browse/CXF-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8059.
> @FormParam inside @BeanParam not working
>
>
> Key: CXF-8059
> URL: https://issues.apache.org/jira/browse/CXF-8059
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.18, 3.2.9, 3.3.2
> Environment: Linux:
> Linux 5.1.9-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 11 16:18:09 UTC 2019 x86_64
> GNU/Linux
> Java:
> openjdk version "1.8.0_212"
> OpenJDK Runtime Environment (build 1.8.0_212-b01)
> OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
>Reporter: Victor Machado Pasqualino
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
>
> class UserInsert {
> @FormParam("name") //not work
> private String name;
> @HeaderParam("Authorization") //work
> private String authorization;
> @PathParam("id") //work
> private String id;
> @QueryParam("login") //work
> private String login;
>
> public void setName(String name) {
> this.name = name;
> }
>
> public void setAuthorization(String authorization) {
> this.authorization = authorization;
> }
>
> public void setId(String id) {
> this.id = id;
> }
>
> public void setLogin(String login) {
> this.login = login;
> }
>
> }
> @Path("user")
> interface UserResource {
>
> @Path("{id}")
> @POST
> @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
> @Produces(MediaType.WILDCARD)
> Response save(@BeanParam UserInsert userInsert);
> }
> public class Main {
>
> public static void main(String[] args) {
>
> WireMockServer wireMockServer = new
> WireMockServer(wireMockConfig().port(8080).notifier(new
> ConsoleNotifier(true)));
> wireMockServer.start();
>
> try {
> UserInsert userInsert = new UserInsert();
> userInsert.setName("Victor Machado Pasqualino");
> userInsert.setAuthorization("Basic YWRtaW46YWRtaW4=");
>
> userInsert.setId("5a4cfa7d-d3bd-4483-968f-b5826ec07712");
> userInsert.setLogin("victorpasqualino");
>
> JAXRSClientFactoryBean jaxrsClientFactory = new
> JAXRSClientFactoryBean();
>
> jaxrsClientFactory.setAddress("http://localhost:8080/rest";);
> jaxrsClientFactory.setResourceClass(UserResource.class);
> jaxrsClientFactory.getOutInterceptors().add(new
> LoggingOutInterceptor());
>
> UserResource userResource =
> jaxrsClientFactory.create(UserResource.class);
>
> userResource.save(userInsert);
> } finally {
> wireMockServer.stop();
> }
>
> }
> }
> Client Request:
> INFO: Outbound Message
> ---
> ID: 1
> Address:
> http://localhost:8080/rest/user/5a4cfa7d-d3bd-4483-968f-b5826ec07712?login=victorpasqualino
> Http-Method: POST
> Content-Type: application/x-www-form-urlencoded
> Headers: {Authorization=[Basic YWRtaW46YWRtaW4=],
> Content-Type=[application/x-www-form-urlencoded], Accept=[application/xml]}
> --
> Server Request:
> 2019-06-19 01:53:29.363 Request was not matched as there were no stubs
> registered:
> {
> "url" :
> "/rest/user/5a4cfa7d-d3bd-4483-968f-b5826ec07712?login=victorpasqualino",
> "absoluteUrl" :
> "http://localhost:8080/rest/user/5a4cfa7d-d3bd-4483-968f-b5826ec07712?login=victorpasqualino";,
> "method" : "POST",
> "clientIp" : "127.0.0.1",
> "headers" : {
> "Authorization" : "Basic YWRtaW46YWRtaW4=",
> "Accept" : "application/xml",
> "Cache-Control" : "no-cache",
> "User-Agent" : "Apache-CXF/3.1.18",
> "Connection" : "keep-alive",
> "Host" : "localhost:8080",
> "Pragma" : "no-cache",
> "Content-Length" : "0",
> "Content-Type" : "application/x-www-form-urlencoded"
> },
> "cookies" : { },
> "browserProxyRequest" : false,
> "loggedDate" : 1560905608975,
> "bodyAsBase64" : "",
> "body" : "",
> "scheme" : "http",
> "host" : "localhost",
> "port" : 8080,
> "loggedDateString" : "2019-06-19T00:53:28Z",
> "queryParams" : {
> "login" : {
> "key" : "login",
> "values" : [ "victorpasqualino" ]
> }
> }
> }
> 2019-06-19 01:53:29.368 Request received:
> 127.0.0.1 - POST
> /rest/user/5a4cfa7d-d3bd-4483-968f-b5826ec07712?login=victor
[jira] [Closed] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8045. > Disable HTTP TRACE method on CXF http-undertow transport > > > Key: CXF-8045 > URL: https://issues.apache.org/jira/browse/CXF-8045 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8046) Resource Listing in CXF 3.3.x does not recognize OpenAPI endpoints
[ https://issues.apache.org/jira/browse/CXF-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8046. > Resource Listing in CXF 3.3.x does not recognize OpenAPI endpoints > -- > > Key: CXF-8046 > URL: https://issues.apache.org/jira/browse/CXF-8046 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Services >Affects Versions: 3.3.1, 3.2.9 >Reporter: Aishwarya S >Assignee: Andriy Redko >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > We have upgraded CXF version from 3.2.x to 3.3.x. And we have also migrated > to OpenAPIFeature from Swagger2Feature. > The URL - *http://:/context/services* will give the resource > listing of all CXF services(in the case of multiple server endpoints) > When we used Swagger2Feature, the above url used to list the swagger json > links too as part of resource listing. But after migrating to OpenAPIFeature, > CXF resource listing does not include Open API JSONs of the CXF Application. > However, We are able to see the Swagger UI if we go to their respective > context URLs. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8060) Automatic ssl configuration using javax.net.ssl.. broken
[
https://issues.apache.org/jira/browse/CXF-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8060.
> Automatic ssl configuration using javax.net.ssl.. broken
>
>
> Key: CXF-8060
> URL: https://issues.apache.org/jira/browse/CXF-8060
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: Vjacheslav Borisov
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.3.3
>
>
> Automatic ssl configuration using javax.net.ssl.. broken (since cxf 3.2.5)
> This is workaround to configure http-conf from system properies
>
>
>
> type="${javax.net.ssl.keyStoreType:JKS}"
> password="${javax.net.ssl.keyStorePassword}"
> file="${javax.net.ssl.keyStore}"/>
>
>
> file="${javax.net.ssl.trustStore}" />
>
>
>
>
> Run JVM with
> -Djavax.net.ssl.trustStore=/path/to/trusted.cacerts
> -Djavax.net.ssl.keyStore=/path/to/trusted.clientcerts
> -Djavax.net.ssl.keyStorePassword=clientcertpass
>
> and try jax-rs client proxy to ssl secured endpoint
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8049) org.apache.cxf.common.util.Compiler fails to compile if a classpath entry contains spaces
[
https://issues.apache.org/jira/browse/CXF-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed CXF-8049.
> org.apache.cxf.common.util.Compiler fails to compile if a classpath entry
> contains spaces
> -
>
> Key: CXF-8049
> URL: https://issues.apache.org/jira/browse/CXF-8049
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.3.2
> Environment: IntelliJ IDEA 2019.1.2 (Ultimate Edition)
> Build #IU-191.7141.44, built on May 7, 2019
> JRE: 1.8.0_202-release-1483-b49 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.3
>
> Using OpenJDK 12 to run/debug my project
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.2.10, 3.3.3
>
> Attachments: workaround.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm trying to create a dynamic client using
> [https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/wsdl_first_dynamic_client/src/main/java/demo/hw/client/ComplexClient.java]
> as a template.
>
> When I try to debug this, I intermittently get a (javac compile) failure
> where
> org.apache.cxf.common.util.Compiler.internalCompile fails because the
> classpath contains an entry with spaces. In my case, this entry with a space
> was a jar from the IntelliJ installation path -
> {{/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar}}
> After spending some time debugging it, I could [^workaround.txt] the problem
> by escaping the said entry from the calling code (ComplexClient.java), but
> maybe this should be done inside org.apache.cxf.common.util.Compiler.addArgs
> where the classpath is being retrieved from the system property
> 'java.class.path'.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (CXF-8081) should cache reactor OutputStream
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8081. > should cache reactor OutputStream > - > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (CXF-8088) ensure jaxrs endpoint can work correctly when using a shared bus exposed from another bundle
[ https://issues.apache.org/jira/browse/CXF-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8088. > ensure jaxrs endpoint can work correctly when using a shared bus exposed from > another bundle > > > Key: CXF-8088 > URL: https://issues.apache.org/jira/browse/CXF-8088 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.2.10, 3.3.3 > > > major 2 issues > 1. not unregister the jaxrs endpoint correctly when stop the jaxrs endpoint > bundle. > 2. jaxrs binding should be added as bus extension so that the bus used by > jaxrs binding factory is always valid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (CXF-7601) Add support for Microprofile OpenAPI implementation (as an alternative to Swagger Core 2.0)
[ https://issues.apache.org/jira/browse/CXF-7601?focusedWorklogId=294939&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-294939 ] ASF GitHub Bot logged work on CXF-7601: --- Author: ASF GitHub Bot Created on: 14/Aug/19 19:05 Start Date: 14/Aug/19 19:05 Worklog Time Spent: 10m Work Description: deki commented on pull request #571: [CXF-7601] Add support for Microprofile OpenAPI implementation URL: https://github.com/apache/cxf/pull/571 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 Issue Time Tracking --- Worklog Id: (was: 294939) Time Spent: 10m Remaining Estimate: 0h > Add support for Microprofile OpenAPI implementation (as an alternative to > Swagger Core 2.0) > --- > > Key: CXF-7601 > URL: https://issues.apache.org/jira/browse/CXF-7601 > Project: CXF > Issue Type: Improvement >Reporter: Dennis Kieselhorst >Assignee: Dennis Kieselhorst >Priority: Minor > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907596#comment-16907596 ] Dennis Kieselhorst commented on CXF-7910: - I've just rebased and updated the branch. Can we resolve the OSGi issues and merge this to master? > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Priority: Minor > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CXF-8089) Build Comma Separated Values in url from Array/List Query Param
[ https://issues.apache.org/jira/browse/CXF-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8089: -- Fix Version/s: 3.3.4 3.2.11 3.4.0 > Build Comma Separated Values in url from Array/List Query Param > --- > > Key: CXF-8089 > URL: https://issues.apache.org/jira/browse/CXF-8089 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.10, 3.3.3 >Reporter: Sridhar >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.4.0, 3.2.11, 3.3.4 > > > https://issues.apache.org/jira/browse/CXF-6941 > Issue reported above is get comma separated values as List on Server side > (for Query Param). > [http://localhost:8080/MovieDB/GetJson?name=Actor1,Actor2,Actor3&startDate=20120101&endDate=2012050|http://localhost:8080/MovieDB/GetJson?name=Actor1,Actor2,Actor3&startDate=20120101&endDate=20120505] > But for Jaxrs- CXF client, when we are trying to build URL from a List or > Array, I don't see a way to build URL as comma separated values > The solution provided to use "parse.query.value.as.collection" contextual > property is not used in org.apache.cxf.jaxrs.client.AbstractClient and > org.apache.cxf.jaxrs.impl.UriBuilderImpl > And works only on server side while receiving request, not on client side > (i.e while building URL from List). > Switching to "multi" option for query param means, I need to ask all existing > clients to update the way they build URL, which is not feasible. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907657#comment-16907657 ] Andriy Redko commented on CXF-7910: --- Hey [~deki], I will try to help with that, unless [~ffang] already solved it :) > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Priority: Minor > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907698#comment-16907698 ] Freeman Fang commented on CXF-7910: --- Hi Guys, The last time I tried, there's still some issues in OSGi test, which should be saaj 1.5 bundle related. I will revisit when I get chance, and another pair of eyes is definitely welcome! Thanks! Freeman > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Priority: Minor > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (CXF-8089) Build Comma Separated Values in url from Array/List Query Param
[ https://issues.apache.org/jira/browse/CXF-8089?focusedWorklogId=295160&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295160 ] ASF GitHub Bot logged work on CXF-8089: --- Author: ASF GitHub Bot Created on: 15/Aug/19 03:07 Start Date: 15/Aug/19 03:07 Worklog Time Spent: 10m Work Description: reta commented on pull request #572: CXF-8089: Build Comma Separated Values in url from Array/List Query Param URL: https://github.com/apache/cxf/pull/572 ### Description The typical style the collection-like query parameters are encoded assumes the repetition of the parameter in question multiple times, for example: http://localhost/books?ids=1&ids=2&ids=3&ids=4 However, as part of https://issues.apache.org/jira/browse/CXF-6941, the CXF server-side includes support for collection query parameters encoded as comma-separated strings, for example: http://localhost/books?ids=1,2,3,4 This is quite useful in many cases however the CXF's client side does not anyhow support this encoding and always uses the repetition (`ids=1&ids=2&ids=3&ids=4`). This PRs complements the client-side feature set. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 Issue Time Tracking --- Worklog Id: (was: 295160) Time Spent: 10m Remaining Estimate: 0h > Build Comma Separated Values in url from Array/List Query Param > --- > > Key: CXF-8089 > URL: https://issues.apache.org/jira/browse/CXF-8089 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.10, 3.3.3 >Reporter: Sridhar >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.4.0, 3.2.11, 3.3.4 > > Time Spent: 10m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/CXF-6941 > Issue reported above is get comma separated values as List on Server side > (for Query Param). > [http://localhost:8080/MovieDB/GetJson?name=Actor1,Actor2,Actor3&startDate=20120101&endDate=2012050|http://localhost:8080/MovieDB/GetJson?name=Actor1,Actor2,Actor3&startDate=20120101&endDate=20120505] > But for Jaxrs- CXF client, when we are trying to build URL from a List or > Array, I don't see a way to build URL as comma separated values > The solution provided to use "parse.query.value.as.collection" contextual > property is not used in org.apache.cxf.jaxrs.client.AbstractClient and > org.apache.cxf.jaxrs.impl.UriBuilderImpl > And works only on server side while receiving request, not on client side > (i.e while building URL from List). > Switching to "multi" option for query param means, I need to ask all existing > clients to update the way they build URL, which is not feasible. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
