[jira] [Updated] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Hlavac updated CXF-7564:
---
Attachment: javaX.log
java0.log
Logs uploaded. {{java0.log}} is using yours logging.properties and javaX.log is
from {{mvn clean install -X}}
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: java0.log, javaX.log, logging.properties,
> wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253092#comment-16253092
]
Michal Hlavac edited comment on CXF-7564 at 11/15/17 8:20 AM:
--
Logs uploaded. {{java0.log}} is using yours logging.properties and
{{javaX.log}} is from {{mvn clean install -X}}
was (Author: hlavki):
Logs uploaded. {{java0.log}} is using yours logging.properties and javaX.log is
from {{mvn clean install -X}}
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: java0.log, javaX.log, logging.properties,
> wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (CXF-7564) codegen-plugin fails on wsdl2java goal
[
https://issues.apache.org/jira/browse/CXF-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Hlavac closed CXF-7564.
--
Resolution: Not A Bug
I found that there were some inconsistencies in maven artefacts. After removing
{{~/.m2/repository/org/apache/cxf}} everything works. Thanks for your time.
> codegen-plugin fails on wsdl2java goal
> --
>
> Key: CXF-7564
> URL: https://issues.apache.org/jira/browse/CXF-7564
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.2.1
> Environment: {code}
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /opt/apache/apache-maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_151/jre
> Default locale: sk_SK, platform encoding: UTF-8
> OS name: "linux", version: "4.13.11-1-default", arch: "amd64", family: "unix"
> {code}
>Reporter: Michal Hlavac
>Assignee: Freeman Fang
> Attachments: java0.log, javaX.log, logging.properties,
> wsdl-example.zip
>
>
> cxf-codegen-plugin fails everytime when running `wsdl2java` goal with error:
> {code}
> Execution generate-wsdl of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.1:wsdl2java failed: Could not find
> jaxws frontend within classpath
> {code}
> Sample project to reproduce issue in attachment. It works if you change
> plugin version to 3.2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FEDIZ-214) OIDC generated already expired id_token
gonzalad created FEDIZ-214: -- Summary: OIDC generated already expired id_token Key: FEDIZ-214 URL: https://issues.apache.org/jira/browse/FEDIZ-214 Project: CXF-Fediz Issue Type: Bug Components: OIDC Affects Versions: 1.4.2 Reporter: gonzalad Priority: Minor Fix For: 1.4.3 id_token expiry claim was is computed from SAML token expiry. Since SAML token is generated once per OIDC httpSession and can be reused for generating multiple id_token, there can be cases where the id_token is generated with an already expired claim. id_token expiry claim should be computed at id_token generation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (FEDIZ-214) OIDC generated already expired id_token
[ https://issues.apache.org/jira/browse/FEDIZ-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-214: - Assignee: Colm O hEigeartaigh > OIDC generated already expired id_token > --- > > Key: FEDIZ-214 > URL: https://issues.apache.org/jira/browse/FEDIZ-214 > Project: CXF-Fediz > Issue Type: Bug > Components: OIDC >Affects Versions: 1.4.2 >Reporter: gonzalad >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 1.4.3 > > > id_token expiry claim was is computed from SAML token expiry. > Since SAML token is generated once per OIDC httpSession > and can be reused for generating multiple id_token, there can be cases > where the id_token is generated with an already expired claim. > id_token expiry claim should be computed at id_token generation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (FEDIZ-214) OIDC generated already expired id_token
[ https://issues.apache.org/jira/browse/FEDIZ-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-214: - Assignee: (was: Colm O hEigeartaigh) > OIDC generated already expired id_token > --- > > Key: FEDIZ-214 > URL: https://issues.apache.org/jira/browse/FEDIZ-214 > Project: CXF-Fediz > Issue Type: Bug > Components: OIDC >Affects Versions: 1.4.2 >Reporter: gonzalad >Priority: Minor > Fix For: 1.4.3 > > > id_token expiry claim was is computed from SAML token expiry. > Since SAML token is generated once per OIDC httpSession > and can be reused for generating multiple id_token, there can be cases > where the id_token is generated with an already expired claim. > id_token expiry claim should be computed at id_token generation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FEDIZ-214) OIDC generated already expired id_token
[ https://issues.apache.org/jira/browse/FEDIZ-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gonzalad closed FEDIZ-214. -- Resolution: Fixed > OIDC generated already expired id_token > --- > > Key: FEDIZ-214 > URL: https://issues.apache.org/jira/browse/FEDIZ-214 > Project: CXF-Fediz > Issue Type: Bug > Components: OIDC >Affects Versions: 1.4.2 >Reporter: gonzalad >Assignee: gonzalad >Priority: Minor > Fix For: 1.4.3 > > > id_token expiry claim was is computed from SAML token expiry. > Since SAML token is generated once per OIDC httpSession > and can be reused for generating multiple id_token, there can be cases > where the id_token is generated with an already expired claim. > id_token expiry claim should be computed at id_token generation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (FEDIZ-214) OIDC generated already expired id_token
[ https://issues.apache.org/jira/browse/FEDIZ-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gonzalad reassigned FEDIZ-214: -- Assignee: gonzalad > OIDC generated already expired id_token > --- > > Key: FEDIZ-214 > URL: https://issues.apache.org/jira/browse/FEDIZ-214 > Project: CXF-Fediz > Issue Type: Bug > Components: OIDC >Affects Versions: 1.4.2 >Reporter: gonzalad >Assignee: gonzalad >Priority: Minor > Fix For: 1.4.3 > > > id_token expiry claim was is computed from SAML token expiry. > Since SAML token is generated once per OIDC httpSession > and can be reused for generating multiple id_token, there can be cases > where the id_token is generated with an already expired claim. > id_token expiry claim should be computed at id_token generation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7562) ext.logging: truncated flag not set
[
https://issues.apache.org/jira/browse/CXF-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253325#comment-16253325
]
ASF GitHub Bot commented on CXF-7562:
-
forsthofer commented on a change in pull request #340: [CXF-7562] correction
for truncated flag
URL: https://github.com/apache/cxf/pull/340#discussion_r151102002
##
File path:
rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingOutInterceptor.java
##
@@ -82,7 +82,10 @@ private OutputStream createCachingOut(Message message,
final OutputStream os, Ca
newOut.setThreshold(threshold);
}
if (limit > 0) {
-newOut.setCacheLimit(limit);
+// make the limit for the cache greater than the limit for the
truncated payload in the log event,
+// this is necessary for finding out that the payload was
truncated
+//(see boolean isTruncated = cos.size() > limit && limit != -1;)
in method copyPayload
+newOut.setCacheLimit(limit + 1);
Review comment:
instead of just setting the limit to 'limit +1' one should check whether the
limit == Integer.MAX_VALUE and if this is the case just use Integer.MAX_VALUE
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
> ext.logging: truncated flag not set
>
>
> Key: CXF-7562
> URL: https://issues.apache.org/jira/browse/CXF-7562
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Franz Forsthofer
> Fix For: 3.1.15, 3.2.2
>
>
> In the ext.logging feature the log event (LogEvent) has the attribute
> truncated which indicates whether the logged payloud was trancated or not.
> This attribute is not set correctly by the interceptors
> - org.apache.cxf.ext.logging.LoggingInInterceptor
> - org.apache.cxf.ext.logging.LoggingOutInterceptor
> I will add a patch via github.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253430#comment-16253430
]
ASF GitHub Bot commented on CXF-7544:
-
reta commented on issue #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344591904
Better solution is required, closing
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253431#comment-16253431
]
ASF GitHub Bot commented on CXF-7544:
-
reta closed pull request #339: CXF-7544: Support @Context-based injection into
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339
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/CdiClassUnwrapper.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
index c32e6690981..ac54da90535 100644
--- a/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
+++ b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
@@ -22,8 +22,18 @@
import org.apache.cxf.common.util.ClassUnwrapper;
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ *
+ * Xxx$$OwbNormalScopeProxy0
+ * Xxx$Proxy$_$$_WeldClientProxy
+ *
+ */
+private static final Pattern PROXY_PATTERN =
Pattern.compile(".+\\$\\$.+Proxy\\d*");
CdiClassUnwrapper() {
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
index ce23e1a924c..823ae5e8291 100644
---
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
+++
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
@@ -27,6 +27,7 @@
import java.util.ServiceLoader;
import java.util.Set;
+import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.context.spi.CreationalContext;
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.AfterBeanDiscovery;
@@ -38,10 +39,13 @@
import javax.enterprise.inject.spi.Extension;
import javax.enterprise.inject.spi.InjectionTarget;
import javax.enterprise.inject.spi.ProcessBean;
+import javax.enterprise.inject.spi.ProcessInjectionTarget;
import javax.enterprise.inject.spi.ProcessProducerField;
import javax.enterprise.inject.spi.ProcessProducerMethod;
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.Path;
+import javax.ws.rs.container.ContainerRequestFilter;
+import javax.ws.rs.container.ContainerResponseFilter;
import javax.ws.rs.core.Application;
import javax.ws.rs.ext.MessageBodyReader;
import javax.ws.rs.ext.MessageBodyWriter;
@@ -51,6 +55,7 @@
import org.apache.cxf.bus.extension.ExtensionManagerBus;
import org.apache.cxf.cdi.event.DisposableCreationalContext;
import org.apache.cxf.cdi.extension.JAXRSServerFactoryCustomizationExtension;
+import org.apache.cxf.cdi.inject.ContextInjectionTarget;
import org.apache.cxf.feature.Feature;
import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
@@ -122,6 +127,21 @@ public void addResourceProvider(final CdiResourceProvider
other) {
}
}
+public void processInjectionTarget(@Observes final
ProcessInjectionTarget target,
+final BeanManager beanManager) {
+
+final InjectionTarget injectionTarget = target.getInjectionTarget();
+final AnnotatedType type = target.getAnnotatedType();
+
+// The beans annotated with @ApplicationScoped will be very likely
proxified.
+boolean isApplicationScoped =
type.isAnnotationPresent(ApplicationScoped.class);
+if (isApplicationScoped && isProvider(type)) {
+// Limit the scope to providers for now
+final InjectionTarget contextual = new
ContextInjectionTarget<>(injectionTarget, type.getJavaClass());
+target.setInjectionTarget(contextual);
+}
+}
+
public void collect(@Observes final ProcessProducerField< T, X >
event) {
final Type baseType = event.getAnnotatedProducerField().getBaseType();
processProducer(event, baseType);
@@ -421,4 +441,16 @@ private void customize(final BeanManager beanManager,
final JAXRSServerFactoryBe
}
}
+/**
+ * Tries to detect of a particular annotated type corresponds to provider
+ * @param type annotated type
+ * @return "true" if annotated type corresponds to provider, "false"
otherwise
+ */
+private boolean isProvider(final AnnotatedType type) {
+return type.isAnnotationPresent(Provider.class)
+||
ContainerRequestFilter.class.isAssignableFrom(type.getJavaClass())
+||
ContainerRespons
[jira] [Commented] (CXF-7535) Support for Project Reactor as rx()
[ https://issues.apache.org/jira/browse/CXF-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253461#comment-16253461 ] Sergey Beryozkin commented on CXF-7535: --- John, re Flux vs Mono in ReactorInvoker. There's no diff in the way it's implemented at the moment. FYI, once you do asyncRespone.resume(), it will take the object whatever it is and will try to return it and the async response will be done. So, if you have Flux returning not a self-contained object and instead a sequence of objects coming in with the Flux async subscriber events, then it won't really work. The same issue was in the RxJava2 invoker but I've just updated it to make it work for a case where a sequence of objects to be serialized as JSON is returned, have a look please, I propose the same be done for Reactor Flux case. One more thing: asyncResponse.complete() is supposed to be called by the CXF runtime only when it detects that the response data have been sent to the client, thus you can safely remove asyncResponse::onComplete() > Support for Project Reactor as rx() > --- > > Key: CXF-7535 > URL: https://issues.apache.org/jira/browse/CXF-7535 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.2.0 >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 3.2.2 > > > It would be good if Project Reactor was supported as an rx() type in CXF. > https://github.com/apache/cxf/tree/master/rt/rs/extensions/rx - only shows rx > java and rx java 2. project reactor/reactor core seem like the v3's of this > api stack. > https://projectreactor.io/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7566) Misleading Fault message "Could not send message"
joel shemtov created CXF-7566: - Summary: Misleading Fault message "Could not send message" Key: CXF-7566 URL: https://issues.apache.org/jira/browse/CXF-7566 Project: CXF Issue Type: Bug Components: Core Reporter: joel shemtov Priority: Minor he interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on its handleMessage() method, adds another interceptor to the interceptor chain. The latter is an instance of an inner class. Its handleMessage() method closes the conduit. The closing might throw an IOException. If that one is caught, it is wrapped in a Fault with the description "Could not send Message". The text is taken from a resource bundle. There's one problem here: On synchronous sending, IOExceptions may be caught here even after a request has been successfully sent. In such case the error message "Could not send Message" confuses the user. SocketTimeoutException is one such case that I've seen where the server response times out, but the user who checks the logs is lead to believe that the request hasn't been sent at all. I saw another example in https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service where it seems to me that the request has been sent and the response was org.apache.cxf.transport.http.HTTPException. I'd suggest a more generic description (like "could not conclude message"). Even no description at all, assuming that the caught exception is properly described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7566) Misleading Fault message "Could not send message"
[ https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] joel shemtov updated CXF-7566: -- Description: The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on its handleMessage() method, adds another interceptor to the interceptor chain. The latter is an instance of an inner class. Its handleMessage() method closes the conduit. The closing might throw an IOException. If that one is caught, it is wrapped in a Fault with the description "Could not send Message". The text is taken from a resource bundle. There's one problem here: On synchronous sending, IOExceptions may be caught here even after a request has been successfully sent. In such case the error message "Could not send Message" confuses the user. SocketTimeoutException is one such case that I've seen where the server response times out, but the user who checks the logs is lead to believe that the request hasn't been sent at all. I saw another example in https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service where it seems to me that the request has been sent and the response was org.apache.cxf.transport.http.HTTPException. I'd suggest a more generic description (like "could not conclude message"). Even no description at all, assuming that the caught exception is properly described, would be better than the current situation. was: he interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on its handleMessage() method, adds another interceptor to the interceptor chain. The latter is an instance of an inner class. Its handleMessage() method closes the conduit. The closing might throw an IOException. If that one is caught, it is wrapped in a Fault with the description "Could not send Message". The text is taken from a resource bundle. There's one problem here: On synchronous sending, IOExceptions may be caught here even after a request has been successfully sent. In such case the error message "Could not send Message" confuses the user. SocketTimeoutException is one such case that I've seen where the server response times out, but the user who checks the logs is lead to believe that the request hasn't been sent at all. I saw another example in https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service where it seems to me that the request has been sent and the response was org.apache.cxf.transport.http.HTTPException. I'd suggest a more generic description (like "could not conclude message"). Even no description at all, assuming that the caught exception is properly described, would be better than the current situation. > Misleading Fault message "Could not send message" > - > > Key: CXF-7566 > URL: https://issues.apache.org/jira/browse/CXF-7566 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: joel shemtov >Priority: Minor > Labels: newbie > > The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on > its handleMessage() method, adds another interceptor to the interceptor > chain. The latter is an instance of an inner class. Its handleMessage() > method closes the conduit. The closing might throw an IOException. If that > one is caught, it is wrapped in a Fault with the description "Could not send > Message". The text is taken from a resource bundle. > There's one problem here: On synchronous sending, IOExceptions may be caught > here even after a request has been successfully sent. In such case the error > message "Could not send Message" confuses the user. SocketTimeoutException is > one such case that I've seen where the server response times out, but the > user who checks the logs is lead to believe that the request hasn't been sent > at all. I saw another example in > https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service > where it seems to me that the request has been sent and the response was > org.apache.cxf.transport.http.HTTPException. > I'd suggest a more generic description (like "could not conclude message"). > Even no description at all, assuming that the caught exception is properly > described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253597#comment-16253597
]
ASF GitHub Bot commented on CXF-7544:
-
sberyozkin commented on issue #339: CXF-7544: Support @Context-based injection
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344625021
Not my fault this PR has been closed :-)
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
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7544) Support @Context-based injection into proxied CDI beans
[
https://issues.apache.org/jira/browse/CXF-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254469#comment-16254469
]
Andriy Redko commented on CXF-7544:
---
No no, not your fault [~sergey_beryozkin] :-D, I think the different approach
with @AroundInvoke would be much safer and better option. It would be quite
different from the current one, I think would be better to have a new PR for it.
> Support @Context-based injection into proxied CDI beans
> ---
>
> Key: CXF-7544
> URL: https://issues.apache.org/jira/browse/CXF-7544
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.13, 3.2.0
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>
> The issue pop up as part of https://github.com/apache/cxf/pull/330
> discussion. In case when provider / feature / resource is a proxied CDI bean,
> the contextual class members (annotated with @Context) are not injected.
> Test case to reproduce:
> {code}
> @ApplicationScoped
> public class BookStoreRequestFilter implements ContainerRequestFilter {
> @Context private ResourceInfo resourceInfo;
>
> @Override
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> // Contextual instances should be injected independently
> if (resourceInfo == null || resourceInfo.getResourceMethod() == null)
> {
> requestContext.abortWith(Response.serverError().build());
> }
> }
> }
> {code}
> CC [~rmannibucau]
> h3. A bit more context
> In some circumstances (like using @ApplicationScoped annotation for example)
> the CDI runtime will create a proxy class for a particular bean. As the
> result, the CXF side is going to bind the particular provider metadata to
> this proxy instance. It looks logical and unambiguous.
> However, the interesting things are happening when CXF will try to inject
> contextual proxies (@Context annotations) into the provider instance. The
> injections are successful but the target object for them will be the proxy
> instance (not the real instance behind it). Consequently, at runtime, when
> the proxy delegates the call to a backing instance, all contextual proxies
> are null in there (simply put, not set).
> h3. How to solve
> Referring to the recent discussions with [~sergeyb], the best solution would
> be to delegate the @Context annotation to CDI framework (as such, relieving
> the CXF from doing the injection work). This proposal may need a support from
> the JAX-RS specification side.
> Simpler (interim?) possible solution would be to complement the CDI injection
> with @Context injection (delegating this work to the CXF as it works right
> now for non-proxy beans and non-CDI deployments). This could be done by
> observing ProcessInjectionTarget events and supplying our own InjectionTarget
> (have working PoC for this approach).
> Regarding constructor injection, it seems like CXF does not support passing
> the arguments to provider constructor (in case of CDI, w/o @Context
> annotation) so I it would be another (separate) issue to look at.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7566) Misleading Fault message "Could not send message"
[ https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] joel shemtov updated CXF-7566: -- Estimated Complexity: Novice (was: Unknown) > Misleading Fault message "Could not send message" > - > > Key: CXF-7566 > URL: https://issues.apache.org/jira/browse/CXF-7566 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: joel shemtov >Priority: Minor > Labels: newbie > > The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on > its handleMessage() method, adds another interceptor to the interceptor > chain. The latter is an instance of an inner class. Its handleMessage() > method closes the conduit. The closing might throw an IOException. If that > one is caught, it is wrapped in a Fault with the description "Could not send > Message". The text is taken from a resource bundle. > There's one problem here: On synchronous sending, IOExceptions may be caught > here even after a request has been successfully sent. In such case the error > message "Could not send Message" confuses the user. SocketTimeoutException is > one such case that I've seen where the server response times out, but the > user who checks the logs is lead to believe that the request hasn't been sent > at all. I saw another example in > https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service > where it seems to me that the request has been sent and the response was > org.apache.cxf.transport.http.HTTPException. > I'd suggest a more generic description (like "could not conclude message"). > Even no description at all, assuming that the caught exception is properly > described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7566) Misleading Fault message "Could not send message"
[ https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] joel shemtov updated CXF-7566: -- Affects Version/s: 3.0.15 3.1.14 3.2.1 > Misleading Fault message "Could not send message" > - > > Key: CXF-7566 > URL: https://issues.apache.org/jira/browse/CXF-7566 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.15, 3.1.14, 3.2.1 >Reporter: joel shemtov >Priority: Minor > Labels: newbie > > The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on > its handleMessage() method, adds another interceptor to the interceptor > chain. The latter is an instance of an inner class. Its handleMessage() > method closes the conduit. The closing might throw an IOException. If that > one is caught, it is wrapped in a Fault with the description "Could not send > Message". The text is taken from a resource bundle. > There's one problem here: On synchronous sending, IOExceptions may be caught > here even after a request has been successfully sent. In such case the error > message "Could not send Message" confuses the user. SocketTimeoutException is > one such case that I've seen where the server response times out, but the > user who checks the logs is lead to believe that the request hasn't been sent > at all. I saw another example in > https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service > where it seems to me that the request has been sent and the response was > org.apache.cxf.transport.http.HTTPException. > I'd suggest a more generic description (like "could not conclude message"). > Even no description at all, assuming that the caught exception is properly > described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CXF-7566) Misleading Fault message "Could not send message"
[ https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] joel shemtov updated CXF-7566: -- Affects Version/s: (was: 3.0.15) > Misleading Fault message "Could not send message" > - > > Key: CXF-7566 > URL: https://issues.apache.org/jira/browse/CXF-7566 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.14, 3.2.1 >Reporter: joel shemtov >Priority: Minor > Labels: newbie > > The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on > its handleMessage() method, adds another interceptor to the interceptor > chain. The latter is an instance of an inner class. Its handleMessage() > method closes the conduit. The closing might throw an IOException. If that > one is caught, it is wrapped in a Fault with the description "Could not send > Message". The text is taken from a resource bundle. > There's one problem here: On synchronous sending, IOExceptions may be caught > here even after a request has been successfully sent. In such case the error > message "Could not send Message" confuses the user. SocketTimeoutException is > one such case that I've seen where the server response times out, but the > user who checks the logs is lead to believe that the request hasn't been sent > at all. I saw another example in > https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service > where it seems to me that the request has been sent and the response was > org.apache.cxf.transport.http.HTTPException. > I'd suggest a more generic description (like "could not conclude message"). > Even no description at all, assuming that the caught exception is properly > described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7566) Misleading Fault message "Could not send message"
[ https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254812#comment-16254812 ] joel shemtov commented on CXF-7566: --- It looks like quite a trivial fix. I'm happy to have this assigned to me. > Misleading Fault message "Could not send message" > - > > Key: CXF-7566 > URL: https://issues.apache.org/jira/browse/CXF-7566 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.14, 3.2.1 >Reporter: joel shemtov >Priority: Minor > Labels: newbie > > The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on > its handleMessage() method, adds another interceptor to the interceptor > chain. The latter is an instance of an inner class. Its handleMessage() > method closes the conduit. The closing might throw an IOException. If that > one is caught, it is wrapped in a Fault with the description "Could not send > Message". The text is taken from a resource bundle. > There's one problem here: On synchronous sending, IOExceptions may be caught > here even after a request has been successfully sent. In such case the error > message "Could not send Message" confuses the user. SocketTimeoutException is > one such case that I've seen where the server response times out, but the > user who checks the logs is lead to believe that the request hasn't been sent > at all. I saw another example in > https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service > where it seems to me that the request has been sent and the response was > org.apache.cxf.transport.http.HTTPException. > I'd suggest a more generic description (like "could not conclude message"). > Even no description at all, assuming that the caught exception is properly > described, would be better than the current situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
