November 2018 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed

by Jan-Willem Gmelig Meyling (Jira)

[ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.sy... ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: {quote} If the transaction is in progress, but {{javax.transaction.Synchronization}} callback cannot be registered due to the transaction being already marked for rollback or in state where {{javax.transaction.Synchronization}} callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. {quote} This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, {{AFTER_FAILURE}} observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the {{AFTER_FAILIURE}} observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the {{AFTER_FAILURE}} observer). This may make it very difficult for someone trying to figure out why the {{AFTER_SUCCESS}} transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: {{quote}} If the transaction is in progress, but {{javax.transaction.Synchronization}} callback cannot be registered due to the transaction being already marked for rollback or in state where {{javax.transaction.Synchronization}} callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. {{quote}} This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, {{AFTER_FAILURE}} observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the {{AFTER_FAILIURE}} observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the {{AFTER_FAILURE}} observer). This may make it very difficult for someone trying to figure out why the {{AFTER_SUCCESS}} transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Major > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > {quote} > If the transaction is in progress, but {{javax.transaction.Synchronization}} callback cannot be registered due to the transaction being already marked for rollback or in state where {{javax.transaction.Synchronization}} callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, {{AFTER_FAILURE}} observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the {{AFTER_FAILIURE}} observer to be invoked if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the {{AFTER_FAILURE}} observer). This may make it very difficult for someone trying to figure out why the {{AFTER_SUCCESS}} transactional observer was never invoked in the first place, even though the transaction did commit. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed

by Jan-Willem Gmelig Meyling (Jira)

[ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.sy... ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: {{quote}} If the transaction is in progress, but {{javax.transaction.Synchronization}} callback cannot be registered due to the transaction being already marked for rollback or in state where {{javax.transaction.Synchronization}} callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. {{quote}} This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, {{AFTER_FAILURE}} observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the {{AFTER_FAILIURE}} observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the {{AFTER_FAILURE}} observer). This may make it very difficult for someone trying to figure out why the {{AFTER_SUCCESS}} transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Major > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > {{quote}} > If the transaction is in progress, but {{javax.transaction.Synchronization}} callback cannot be registered due to the transaction being already marked for rollback or in state where {{javax.transaction.Synchronization}} callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {{quote}} > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, {{AFTER_FAILURE}} observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the {{AFTER_FAILIURE}} observer to be invoked if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the {{AFTER_FAILURE}} and {{AFTER_COMPLETION}} observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the {{AFTER_FAILURE}} observer). This may make it very difficult for someone trying to figure out why the {{AFTER_SUCCESS}} transactional observer was never invoked in the first place, even though the transaction did commit. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

Passed: cdi-spec/cdi#398 (2.0.1 - e8af649)

by Travis CI

Build Update for cdi-spec/cdi ------------------------------------- Build: #398 Status: Passed Duration: 4 mins and 10 secs Commit: e8af649 (2.0.1) Author: Antoine Sabot-Durand Message: Prepare for 2.0.1 release View the changeset: https://github.com/cdi-spec/cdi/compare/2.0.1 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/461320578?utm_medium=notificati... -- You can unsubscribe from build emails from the cdi-spec/cdi repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=858873&u.... Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notifica.... Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-740: ----------------------------------- This is a known limitation. You are only safe in directly accessing beans when the scope is dependent. Soon as there is a client proxy in play, you need to use methods which will delegate to actual bean instance in the context (as opposed to proxy itself which is a different object - which is why you still see 0 there). Related issues CDI-446 and CDI-244 > Proxy fields can be accessed if they are protected or package private > --------------------------------------------------------------------- > > Key: CDI-740 > URL: https://issues.jboss.org/browse/CDI-740 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Contexts, Java EE integration > Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform > Reporter: Frigo Coder > Priority: Major > > CDI detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8: > {code:java} > @ApplicationScoped > public class Car { > @Inject > private Engine engine; > public int numberOfEngineCylinders() { > return engine.cylinders; > } > } > @RequestScoped > public class Engine { > protected int cylinders; > @PostConstruct > public void init() { > cylinders = 8; > } > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-739?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-739: ----------------------------------- The producer in your example is {{@Dependent}}, e.g. invoked again for every {{InjectionPoint}} of type {{String}} with qualifier {{@UserName}}. The lifecycle of the produced bean is then tied to that into which you injected it - in your case that is application scoped bean, so yea, you inject it once and have it there until app exits (at which point App scope is torn down). bq. CDI should fail to start when it detects such a situation. Such a detection would potentially cost you a lot of time during bootstrap and still fail for cases with {{Instance}}. > Scope mismatch can lead to subtle bugs > -------------------------------------- > > Key: CDI-739 > URL: https://issues.jboss.org/browse/CDI-739 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Contexts, Java EE integration > Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform > Reporter: Frigo Coder > Priority: Major > > CDI allows injection of a non-proxyable object created by a provider into higher level contextes. This can lead to subtle bugs, see the following example, the first username that accesses the service is returned for other users: > {code:java} > @ApplicationScoped > public class ServiceClass { > @Inject > @UserName > private String userName; > } > @RequestScoped > public class UserNameProvider { > @Inject > private HttpServletRequest request; > @Produces > @UserName > public String userName() { > return request.getUserPrincipal().getName(); > } > } > {code} > CDI should fail to start when it detects such a situation. Do note that this bug does not require direct injection (Service->userName), it can occur transitively as well (Service->User->userName). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs

by Frigo Coder (Jira)

[ https://issues.jboss.org/browse/CDI-739?page=com.atlassian.jira.plugin.sy... ] Frigo Coder updated CDI-739: ---------------------------- Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform > Scope mismatch can lead to subtle bugs > -------------------------------------- > > Key: CDI-739 > URL: https://issues.jboss.org/browse/CDI-739 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Contexts, Java EE integration > Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform > Reporter: Frigo Coder > Priority: Major > > CDI allows injection of a non-proxyable object created by a provider into higher level contextes. This can lead to subtle bugs, see the following example, the first username that accesses the service is returned for other users: > {code:java} > @ApplicationScoped > public class ServiceClass { > @Inject > @UserName > private String userName; > } > @RequestScoped > public class UserNameProvider { > @Inject > private HttpServletRequest request; > @Produces > @UserName > public String userName() { > return request.getUserPrincipal().getName(); > } > } > {code} > CDI should fail to start when it detects such a situation. Do note that this bug does not require direct injection (Service->userName), it can occur transitively as well (Service->User->userName). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private

by Frigo Coder (Jira)

Frigo Coder created CDI-740: ------------------------------- Summary: Proxy fields can be accessed if they are protected or package private Key: CDI-740 URL: https://issues.jboss.org/browse/CDI-740 Project: CDI Specification Issues Issue Type: Bug Components: Beans, Contexts, Java EE integration Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform Reporter: Frigo Coder CDI detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8: {code:java} @ApplicationScoped public class Car { @Inject private Engine engine; public int numberOfEngineCylinders() { return engine.cylinders; } } @RequestScoped public class Engine { protected int cylinders; @PostConstruct public void init() { cylinders = 8; } } {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs

by Frigo Coder (Jira)

[ https://issues.jboss.org/browse/CDI-739?page=com.atlassian.jira.plugin.sy... ] Frigo Coder updated CDI-739: ---------------------------- Priority: Major (was: Minor) > Scope mismatch can lead to subtle bugs > -------------------------------------- > > Key: CDI-739 > URL: https://issues.jboss.org/browse/CDI-739 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Contexts, Java EE integration > Reporter: Frigo Coder > Priority: Major > > CDI allows injection of a non-proxyable object created by a provider into higher level contextes. This can lead to subtle bugs, see the following example, the first username that accesses the service is returned for other users: > {code:java} > @ApplicationScoped > public class ServiceClass { > @Inject > @UserName > private String userName; > } > @RequestScoped > public class UserNameProvider { > @Inject > private HttpServletRequest request; > @Produces > @UserName > public String userName() { > return request.getUserPrincipal().getName(); > } > } > {code} > CDI should fail to start when it detects such a situation. Do note that this bug does not require direct injection (Service->userName), it can occur transitively as well (Service->User->userName). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs

by Frigo Coder (Jira)

[ https://issues.jboss.org/browse/CDI-739?page=com.atlassian.jira.plugin.sy... ] Frigo Coder updated CDI-739: ---------------------------- Steps to Reproduce: - Create a @RequestScoped provider - Return a non-proxyable object from it - @Inject the object into an @ApplicationScoped bean - Call the bean once to initialize the object - Call the bean subsequent times - Watch the object stay the same and incorrect for subsequent calls was: - Create a @RequestScoped provider - Return a non-proxyable object from it - @Inject the object into an @ApplicationScoped bean - Call the bean once to initialize the object - Call the bean subsequent times and watch the object stay the same > Scope mismatch can lead to subtle bugs > -------------------------------------- > > Key: CDI-739 > URL: https://issues.jboss.org/browse/CDI-739 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Contexts, Java EE integration > Reporter: Frigo Coder > Priority: Minor > > CDI allows injection of a non-proxyable object created by a provider into higher level contextes. This can lead to subtle bugs, see the following example, the first username that accesses the service is returned for other users: > {code:java} > @ApplicationScoped > public class ServiceClass { > @Inject > @UserName > private String userName; > } > @RequestScoped > public class UserNameProvider { > @Inject > private HttpServletRequest request; > @Produces > @UserName > public String userName() { > return request.getUserPrincipal().getName(); > } > } > {code} > CDI should fail to start when it detects such a situation. Do note that this bug does not require direct injection (Service->userName), it can occur transitively as well (Service->User->userName). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs

by Frigo Coder (Jira)

Frigo Coder created CDI-739: ------------------------------- Summary: Scope mismatch can lead to subtle bugs Key: CDI-739 URL: https://issues.jboss.org/browse/CDI-739 Project: CDI Specification Issues Issue Type: Bug Components: Beans, Contexts, Java EE integration Reporter: Frigo Coder CDI allows injection of a non-proxyable object created by a provider into higher level contextes. This can lead to subtle bugs, see the following example, the first username that accesses the service is returned for other users: {code:java} @ApplicationScoped public class ServiceClass { @Inject @UserName private String userName; } @RequestScoped public class UserNameProvider { @Inject private HttpServletRequest request; @Produces @UserName public String userName() { return request.getUserPrincipal().getName(); } } {code} CDI should fail to start when it detects such a situation. Do note that this bug does not require direct injection (Service->userName), it can occur transitively as well (Service->User->userName). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2018