[JBoss JIRA] (WFLY-11907) NPE trying to use Resteasy Client inside CDI Async Event
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11907?page=com.atlassian.jira.plugin... ]
Matej Novotny edited comment on WFLY-11907 at 3/26/19 10:52 AM:
----------------------------------------------------------------
[~mkopecky] what exactly does RestEasy expect from CDI in {{ResteasyClientBuilder.newBuilder().build();}}?
Because doing events in async manner means that a different thread pool will be used and with that comes a "loss of context" since contexts are mostly thread bound.
CDI will [activate request scope during the asynchronous notification of observer|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#request_context] (meaning you won't get context not active exception), however, the state of the context is *not* preserved (no context propagation). Any request scoped beans will be created anew.
was (Author: manovotn):
[~mkopecky] what exactly does RestEasy expect from CDI in {{ResteasyClientBuilder.newBuilder().build();}}?
Because doing events in async manner means that a different thread pool will be used and with that comes a "loss of context" since contexts are mostly thread bound.
CDI will activate request scope during the asynchronous notification of observer (meaning you won't get context not active exception), however, the state of the context is *not* preserved (no context propagation). Any request scoped beans will be created anew.
> NPE trying to use Resteasy Client inside CDI Async Event
> --------------------------------------------------------
>
> Key: WFLY-11907
> URL: https://issues.jboss.org/browse/WFLY-11907
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 14.0.0.Final, 16.0.0.Final
> Reporter: Cody Lerum
> Assignee: Matej Novotny
> Priority: Major
>
> When attempting to use the Resteasy Client inside a CDI Async Event a NPE is thrown.
> {code}
> 12:49:33,513 ERROR [stderr] (Weld Thread Pool -- 4) java.lang.RuntimeException: java.lang.NullPointerException
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:49)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.getProviderFactory(ResteasyClientBuilder.java:362)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:395)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:38)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.load(ResteasyClientEventObserver.java:28)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.observeAsync(ResteasyClientEventObserver.java:23)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.reflect.Method.invoke(Method.java:498)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.MethodInvocationStrategy$DefaultMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:109)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.util.Observers.notify(Observers.java:166)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.notifyAsyncObserver(ObserverNotifier.java:413)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$notifyAsyncObservers$5(ObserverNotifier.java:356)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$null$8(ObserverNotifier.java:438)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.security.spi.SecurityServices.lambda$getSecurityContextAssociator$0(SecurityServices.java:80)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$createSupplier$9(ObserverNotifier.java:435)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run$$$capture(CompletableFuture.java:1590)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.Thread.run(Thread.java:748)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) Caused by: java.lang.NullPointerException
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.registerProviders(RegisterBuiltin.java:60)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:45)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (WFLY-11907) NPE trying to use Resteasy Client inside CDI Async Event
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11907?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11907:
--------------------------------------
[~mkopecky] what exactly does RestEasy expect from CDI in {{ResteasyClientBuilder.newBuilder().build();}}?
Because doing events in async manner means that a different thread pool will be used and with that comes a "loss of context" since contexts are mostly thread bound.
CDI will activate request scope during the asynchronous notification of observer (meaning you won't get context not active exception), however, the state of the context is *not* preserved (no context propagation). Any request scoped beans will be created anew.
> NPE trying to use Resteasy Client inside CDI Async Event
> --------------------------------------------------------
>
> Key: WFLY-11907
> URL: https://issues.jboss.org/browse/WFLY-11907
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 14.0.0.Final, 16.0.0.Final
> Reporter: Cody Lerum
> Assignee: Matej Novotny
> Priority: Major
>
> When attempting to use the Resteasy Client inside a CDI Async Event a NPE is thrown.
> {code}
> 12:49:33,513 ERROR [stderr] (Weld Thread Pool -- 4) java.lang.RuntimeException: java.lang.NullPointerException
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:49)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.getProviderFactory(ResteasyClientBuilder.java:362)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:395)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:38)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.load(ResteasyClientEventObserver.java:28)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.observeAsync(ResteasyClientEventObserver.java:23)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.reflect.Method.invoke(Method.java:498)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.MethodInvocationStrategy$DefaultMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:109)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
> 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.util.Observers.notify(Observers.java:166)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.notifyAsyncObserver(ObserverNotifier.java:413)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$notifyAsyncObservers$5(ObserverNotifier.java:356)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$null$8(ObserverNotifier.java:438)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.security.spi.SecurityServices.lambda$getSecurityContextAssociator$0(SecurityServices.java:80)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$createSupplier$9(ObserverNotifier.java:435)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run$$$capture(CompletableFuture.java:1590)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.Thread.run(Thread.java:748)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) Caused by: java.lang.NullPointerException
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.registerProviders(RegisterBuiltin.java:60)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:45)
> 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (WFLY-11898) Add ability to group distributed session attributes to avoid cost of SESSION granularity
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11898?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-11898:
--------------------------------
Description:
Since SESSION granularity requires the replication of *all* session attribute if *any* attribute was modified in a given request, most distributed web applications should leverage ATTRIBUTE granularity whenever to possible to reduce the replication payload costs per request.
However, if session attribute contains any reference to another session attribute, they are forced to use SESSION granularity to avoid losing referential integrity on failover and duplication of serialized data.
The proposal is to allow users the ability to annotate their session attribute classes such that they can group specific attribute together, while still being able to leverage ATTRIBUTE granularity for the remainder of their session attributes.
>From the user's perspective, I envision something like this:
{code:java}
@SessionAttributeGroup("order")
public class Order implements Serializable {
List<OrderItem> items;
}
@SessionAttributeGroup("order")
public class OrderItem implements Serializable {
//...
}
{code}
Thus the code:
{code:java}
session.setAttribute("order", order);
session.setAttribute("customized-item", item);
{code}
will result in both attributes being store within a single cache entry.
Internally, we use the @SessionAttributeGroup as the attribute name, and a Map<String, Object> as the attribute value, keyed by the actual attribute name.
was:
Since SESSION granularity requires the replication of *all* session attribute if *any* attribute was modified in a given request, most distributed web applications should leverage ATTRIBUTE granularity whenever to possible to reduce the replication payload costs per request.
However, if session attribute contains any reference to another session attribute, they are forced to use SESSION granularity to avoid losing referential integrity on failover and duplication of serialized data.
The proposal is to allow users the ability to annotate their session attribute classes such that they can group specific attribute together, while still being able to leverage ATTRIBUTE granularity for the remainder of their session attributes.
>From the user's perspective, I envision something like this:
@SessionAttributeGroup("order")
public class Order implements Serializable {
List<OrderItem> items;
}
@SessionAttributeGroup("order")
public class OrderItem implements Serializable {
//...
}
Thus the code:
session.setAttribute("order", order);
session.setAttribute("customized-item", item);
will result in both attributes being store within a single cache entry.
Internally, we use the @SessionAttributeGroup as the attribute name, and a Map<String, Object> as the attribute value, keyed by the actual attribute name.
> Add ability to group distributed session attributes to avoid cost of SESSION granularity
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-11898
> URL: https://issues.jboss.org/browse/WFLY-11898
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 16.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Since SESSION granularity requires the replication of *all* session attribute if *any* attribute was modified in a given request, most distributed web applications should leverage ATTRIBUTE granularity whenever to possible to reduce the replication payload costs per request.
> However, if session attribute contains any reference to another session attribute, they are forced to use SESSION granularity to avoid losing referential integrity on failover and duplication of serialized data.
> The proposal is to allow users the ability to annotate their session attribute classes such that they can group specific attribute together, while still being able to leverage ATTRIBUTE granularity for the remainder of their session attributes.
> From the user's perspective, I envision something like this:
> {code:java}
> @SessionAttributeGroup("order")
> public class Order implements Serializable {
> List<OrderItem> items;
> }
> @SessionAttributeGroup("order")
> public class OrderItem implements Serializable {
> //...
> }
> {code}
> Thus the code:
> {code:java}
> session.setAttribute("order", order);
> session.setAttribute("customized-item", item);
> {code}
> will result in both attributes being store within a single cache entry.
> Internally, we use the @SessionAttributeGroup as the attribute name, and a Map<String, Object> as the attribute value, keyed by the actual attribute name.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months