[JBoss JIRA] (CDI-180) Clarify request context lifecycle during remote method invocation of EJB
by Martin Kouba (Created) (JIRA)
Clarify request context lifecycle during remote method invocation of EJB
------------------------------------------------------------------------
Key: CDI-180
URL: https://issues.jboss.org/browse/CDI-180
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.0
Reporter: Martin Kouba
CDI 1.0 spec states in *6.7.1. Request context lifecycle*:
"The request scope is active: during any remote method invocation of any EJB" and "The request context is destroyed: after the EJB remote method invocation"
However it doesn't cover various invocation scenarios. For example it's possible to do in-VM invocation (via remote interface) from the same deployment or from a different deployment. Is the request context shared in this case? Will be destroyed after the EJB remote method invocation?
Also take into account that application servers often do optimization and handle remote interface calls in a local interface manner within the same JVM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
CDI + transactions query
by Pete Muir
Hi Paul, Tom, Mike,
I have an open issue in CDI - https://issues.jboss.org/browse/CDI-213 - which I would like your input on.
Events in CDI are very simple (you can read more at http://docs.jboss.org/weld/reference/latest/en-US/html/events.html) and provide a typesafe implementation of the observer/observable pattern. Currently the spec prohibits manipulating transactions from an observer method, but it doesn't say what happens if someone does try to do this [1].
So, what I'm asking is really whether it really makes no sense to allow this, or whether it's best to say that it's "non-portable", which means that an implemenation might offer this as a feature above and beyond the spec. Furthermore, it may be that it's not really possible to disallow this, in which case we would need to go with non-portable as well.
Thanks
Pete
[1] If we say that it leads to an exception, we can then check it in the TCK, which is good :-)
14 years
[JBoss JIRA] (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ]
Jens Schumann commented on CDI-75:
----------------------------------
>From my mail to cdi-dev:
Initially I thought it would be a good idea to ignore an observer method
if a scope is not active and notifyObserver is IF_EXISTS. But now I
believe this is partially wrong. Too me there is a difference between
A) the observer bean scope is active without an active bean in scope and
B) the observer bean scope is not active
IF_EXISTS refers to A) only, I believe. Because if IF_EXISTS applies to A)
and B) I am unable to support ALWAYS for active scopes while being ignored
if a scope is not active.
Why would someone need that? Very often we initialize our application
during startup. During startup request and application scope are active.
Usually a session scoped observer should be ignored during startup.
But at runtime - with an active session scope - I need ALWAYS semantics
for those observers.
So I would vote for:
- ALWAYS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will be ignored if scope is active but no
active bean is in scope.
- (The newly created) IF_ACTIVE observer method (naming TBD) will be
ignored if scope is inactive. If scope is active it will be treated as
ALWAYS.
- There might be a need for IF_ACTIVE_AND_EXISTS;).
This might break backwards compatibility though.
> Clarify what happens to a bean which belongs to inactive when it observes an event
> ----------------------------------------------------------------------------------
>
> Key: CDI-75
> URL: https://issues.jboss.org/browse/CDI-75
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ]
Jens Schumann edited comment on CDI-75 at 8/30/12 2:17 PM:
-----------------------------------------------------------
>From my mail to cdi-dev:
Initially I thought it would be a good idea to ignore an observer method
if a scope is not active and notifyObserver is IF_EXISTS. But now I
believe this is partially wrong. There is a difference between
A) the observer bean scope is active without an active bean in scope and
B) the observer bean scope is not active
IF_EXISTS refers to A) only, I believe. Because if IF_EXISTS applies to A)
and B) I am unable to support ALWAYS for active scopes while being ignored
if a scope is not active.
Why would someone need that? Very often we initialize our application
during startup. During startup request and application scope are active.
Usually a session scoped observer should be ignored during startup.
But at runtime - with an active session scope - I need ALWAYS semantics
for those observers.
So I would vote for:
- ALWAYS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will be ignored if scope is active but no
active bean is in scope.
- (The newly created) IF_ACTIVE observer method (naming TBD) will be
ignored if scope is inactive. If scope is active it will be treated as
ALWAYS.
- There might be a need for IF_ACTIVE_AND_EXISTS;).
This might break backwards compatibility though.
was (Author: french_c):
From my mail to cdi-dev:
Initially I thought it would be a good idea to ignore an observer method
if a scope is not active and notifyObserver is IF_EXISTS. But now I
believe this is partially wrong. Too me there is a difference between
A) the observer bean scope is active without an active bean in scope and
B) the observer bean scope is not active
IF_EXISTS refers to A) only, I believe. Because if IF_EXISTS applies to A)
and B) I am unable to support ALWAYS for active scopes while being ignored
if a scope is not active.
Why would someone need that? Very often we initialize our application
during startup. During startup request and application scope are active.
Usually a session scoped observer should be ignored during startup.
But at runtime - with an active session scope - I need ALWAYS semantics
for those observers.
So I would vote for:
- ALWAYS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will throw an ContextNotActiveException(?) if
scope is not active.
- IF_EXISTS observer methods will be ignored if scope is active but no
active bean is in scope.
- (The newly created) IF_ACTIVE observer method (naming TBD) will be
ignored if scope is inactive. If scope is active it will be treated as
ALWAYS.
- There might be a need for IF_ACTIVE_AND_EXISTS;).
This might break backwards compatibility though.
> Clarify what happens to a bean which belongs to inactive when it observes an event
> ----------------------------------------------------------------------------------
>
> Key: CDI-75
> URL: https://issues.jboss.org/browse/CDI-75
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
Event type
by Marko Lukša
I have been reading the spec about events and I'm a little confused.
In "Chapter 10. Events", the spec says:
* An event comprises: - A Java object—the/event object/
* The event object acts as a payload
* An observer method will be notified of an event if the *event object
is assignable to the observed event type
*
I understand this to mean that the actual payload is what's important
when resolving observer methods. Yet, this is not true when firing
events through the Event bean. When firing events through the Event
bean, observers are resolved according to the type parameter of the
injected Event bean (or the type passed to event.select()) and not the
actual type of payload supplied to event.fire(payload) (see
https://issues.jboss.org/browse/WELD-672).
In WELD, the actual type of the payload is only important when firing
events through BeanManager.fireEvent(), which is not even mentioned in
"10.3. Firing events". From 10.3, I would expect that the usual way of
firing events is through the Event bean, and firing events through the
BeanManager is the low-level way of doing it.
I have a few more questions, but they are all inter-dependent, so it's
probably better if you help me resolve this one first, and then I'll
move on to the rest.
Marko
14 years
Scoped CDI Events?
by Adam Bien
Hi *,
I didn't found in the CDI 1.0 spec a mention of the scope of CDI events. There is also no mention of scopes in the Observer Resolution section.
Are CDI events scoped?
Does observer resolution depend on the scope of the injected Event instance?
Should we refine/clarify that in the CDI 1.1 spec?
I didn't found an explicit mail in the archives either,
thanks and sorry in case the issue is already resolved,
adam
14 years
[JBoss JIRA] (CDI-252) Allow transaction control inside observer methods
by Pete Muir (JIRA)
Pete Muir created CDI-252:
-----------------------------
Summary: Allow transaction control inside observer methods
Key: CDI-252
URL: https://issues.jboss.org/browse/CDI-252
Project: CDI Specification Issues
Issue Type: Bug
Components: Events, Java EE integration
Affects Versions: 1.1.EDR
Reporter: Pete Muir
Fix For: TBD
>From Tom Jenkinson
{quote}
Would it make sense to maintain the same restrictions as JMS?
In JMS you can initiate a new transaction from onMessage, analogous to a method decorated with @Observes. If the method returns without completing the transaction then an error is logged and the transaction rolled back.
Flowing a transaction from an event producer to an event consumer isn't a great idea (it doesn't work in JMS either). But allowing a consumer to control their own transaction does seem to make sense to me.
Admittedly this is a gut reaction, I read through the Jira and the doc you linked to though, and used my JEE experience to draw analogies, do let me know if I got the wrong end of the stick please!
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (CDI-216) @Veto and ProcessAnnotatedType
by Gerhard Petracek (JIRA)
Gerhard Petracek created CDI-216:
------------------------------------
Summary: @Veto and ProcessAnnotatedType
Key: CDI-216
URL: https://issues.jboss.org/browse/CDI-216
Project: CDI Specification Issues
Issue Type: Clarification
Components: Concepts, Packaging and Deployment
Affects Versions: 1.1.EDR1
Reporter: Gerhard Petracek
Priority: Critical
currently the spec. specifies:
"The container must fire an event for each Java class or interface it discovers in a bean archive, and for annotated type added by BeforeBeanDiscovery.addAnnotatedType(), before it reads the declared annotations."
that's ok for cdi 1.0.
however, if @Veto gets added to cdi 1.1, we need a clarification here.
the internal implementation via a std. cdi doesn't make sense because other extensions still get the corresponding ProcessAnnotatedType event.
-> Annotated types with @Veto (or as suggested at CDI-50: @Unmanaged or @Exclude) shouldn't lead to a ProcessAnnotatedType event.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
