[weld-issues] [JBoss JIRA] (WELD-2444) Transactional observer cannot be fired from another transaction synchronisation
Title: Message Title
Jan-Willem Gmelig Meyling updated an issue
Weld / WELD-2444
Transactional observer cannot be fired from another transaction synchronisation
Change By:
Jan-Willem Gmelig Meyling
When firing an CDI event from another transaction synchronisation, the {{TransactionalObserverNotifier}} fails to defer the notification, because registering the {{TransactionSynchronizedRunnable}} fails with an "ARJUNA016082: Synchronizations are not allowed".In my case this for example happens when I fire the event from a JPA Lifecycle listener, which is triggered by the flush call on the {{EntityManager}} through Hibernates {{JtaTransactionCoordinatorImpl}} bound in the {{JCAOrderedLastSynchronizationList}}.The current behaviour has one very odd side effect: namely, the exception is swallowed in the {{TransactionalObserverNotifier}}, which then notifies a filtered set of observers, assuming that a rollback exception must have occurred. As a result, the {{AFTER_FAILURE}} observers are invoked and not the {{AFTER_SUCCESS}} observers, even though the transaction commits successfully (because the {{IllegalStateException}} was caused by not being able to register the synchronisation, and not due to the fact that the transaction failed altogether).I think the error handling should be fixed, because it seems odd that {{AFTER_FAILURE}} observers get invoked for a successful transaction.Furthermore it would be nice to actually support events with transactional observers to be fired from another synchronisation. I am not entirely sure whether it is feasible to support, but I am having a couple of ideas:* an implementation where we just register a synchronisation by default and handle the synchronisation from there, rather than registering the synchronisation on the transaction just in time* Hook on the {{JCAOrderedLastSynchronizationList}} instead of the Transaction, just as Hibernate seems to do* Register an _interposed_ synchronisation with the {{TransactionSynchronizationRegistry}} rather than a regular synchronisation.Some more background (a stack trace) can be found in the Stackoverflow issue: https://stackoverflow.com/questions/47953827/defer-transactionalobservernotifier-fails-with-arjuna016082-synchronizations-ar Also of interest can be the blogpost describing how to fire CDI events from JPA lifecycle listeners: http://blogs.bytecode.com.au/glen/2014/01/09/firing-cdi-events-from-a-jpa-entitylistener.html . Keep in mind that this has become much more natural to do since CDI injection is since allowed into {{EntityListeners}} as of JPA 2.1.
[weld-issues] [JBoss JIRA] (WELD-2548) StackOverFlow when used with EL and JSF
Title: Message Title
Matej Novotny edited a comment on WELD-2548
Re: StackOverFlow when used with EL and JSF
The problem is that there is a registered bean ([coming from JSF impl|https://github.com/javaserverfaces/mojarra/blob/master/impl/src/main/java/com/sun/faces/cdi/RequestMapProducer.java]) of type {{com.sun.faces.context.RequestMap}} which is just a little more fancier {{Map}}.One of the elements of this map (stored under key {{"org.jboss.weld.context.http.HttpRequestContext#com.sun.faces.cdi.RequestMapProducer"}} is the Map itself.This OFC blows up when you try to do {{Map.toString()}} which is what using the EL _expression_ ultimately does. Now When Weld is given the bean instance from JSF, e.g. when it is first accessed, creation process is triggered followed by storing the bean in our bean store for request scoped beans. This store is a write through cache which goes straight to {{HTTPServletRequest.setAtribute()}} - e.g. we "just" put the bean right back into the HTTP request which goes into the map.This is essentially correct as we need to figure out whos store all beans there, this SO error is populating only because of this map with itself recursive {{toString()}} call . Same story should go for {{#sessionMap}} only neither the original reproducer not the one in our TS actually triggers session creation . We should verify that as well .
Add Comment
This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2444) Transactional observer cannot be fired from another transaction synchronisation
Title: Message Title
Jan-Willem Gmelig Meyling updated an issue
Weld / WELD-2444
Transactional observer cannot be fired from another transaction synchronisation
Change By:
Jan-Willem Gmelig Meyling
When firing an CDI event from another transaction synchronisation, the {{ TransactionalObserverNotifier }} fails to defer the notification, because registering the {{ TransactionSynchronizedRunnable }} fails with an "ARJUNA016082: Synchronizations are not allowed".In my case this for example happens when I fire the event from a JPA Lifecycle listener, which is triggered by the flush call on the {{ EntityManager }} through Hibernates {{ JtaTransactionCoordinatorImpl }} bound in the {{ JCAOrderedLastSynchronizationList }} .The current behaviour has one very odd side effect: namely, the exception is swallowed in the {{ TransactionalObserverNotifier }} , which then notifies a filtered set of observers, assuming that a rollback exception must have occurred. As a result, the ` {{ AFTER_FAILURE ` }} observers are invoked and not the ` {{ AFTER_SUCCESS ` }} observers, even though the transaction commits successfully (because the {{ IllegalStateException }} was caused by not being able to register the synchronisation, and not due to the fact that the transaction failed altogether).I think the error handling should be fixed, because it seems odd that {{ AFTER_FAILURE }} observers get invoked for a successful transaction.Furthermore it would be nice to actually support events with transactional observers to be fired from another synchronisation. I am not entirely sure whether it is feasible to support, but I am having a couple of ideas:* an implementation where we just register a synchronisation by default and handle the synchronisation from there, rather than registering the synchronisation on the transaction just in time* Hook on the {{ JCAOrderedLastSynchronizationList }} instead of the Transaction, just as Hibernate seems to do* Register an interposed _interposed_ synchronisation with the {{TransactionSynchronizationRegistry}} rather than a regular synchronisation.Some more background (a stack trace) can be found in the Stackoverflow issue: https://stackoverflow.com/questions/47953827/defer-transactionalobservernotifier-fails-with-arjuna016082-synchronizations-ar
[weld-issues] [JBoss JIRA] (WELD-2548) StackOverFlow when used with EL and JSF
Title: Message Title Matej Novotny commented on WELD-2548 Re: StackOverFlow when used with EL and JSF The problem is that there is a registered bean (coming from JSF impl) of type com.sun.faces.context.RequestMap which is just a little more fancier Map. One of the elements of this map (stored under key "org.jboss.weld.context.http.HttpRequestContext#com.sun.faces.cdi.RequestMapProducer" is the Map itself. This OFC blows up when you try to do Map.toString() which is what using the EL _expression_ ultimately does. Now we "just" need to figure out whos is populating this map with itself... Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2550) InterceptionFactory with loosened limitation on interfaces
Title: Message Title
Xavier Dury commented on WELD-2550
Re: InterceptionFactory with loosened limitation on interfaces
Nice! I'd like to point out that while you lose interceptor bindings (declared on the instance's class) when using an interface on the InterceptionFactory, you still retain the possibility to parameterize the InterceptionFactory with the target instance's class (and not losing anything). This makes me think that all interceptor bindings could maybe come from the parameter type (+ configurator) and the proxyability requirement could also be on that parameter type rather than on the instance's type... but that would be a change in the current spec. After all, a producer method returning an interface does not seem to take into account the concrete type of the returned object (nor all other interfaces it might implement). This can be tweaked with @Typed. Alternatively and thinking out loud, we could maybe control what type(s) a proxy should be made of with something like this:
@Produces
SomeInterface bean(@Typed({SomeInterface.class, SomeOtherInterface.class}) InterceptionFactory factory) { ... }
or with a new method on InterceptionFactory like setProxyTypes(Class...)... but these are just ideas thrown in there.
Add Comment
This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505)
[weld-issues] [JBoss JIRA] (WELD-2549) Translator example cannot be deployed to WFLY 14
Title: Message Title Matej Novotny closed an issue as Rejected Closing as rejected, this isn't Weld bug but WFLY bug. Will be resolved as a part of WFLY-11432. Weld / WELD-2549 Translator example cannot be deployed to WFLY 14 Change By: Matej Novotny Status: Open Closed Fix Version/s: 3.1.0.Final Resolution: Rejected Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505)
