[JBoss JIRA] (CDI-371) Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-371?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-371:
-------------------------------
MDBs have not "been removed" at all. The only change was that we do not allow them to be decorated, as we have no way of binding a decorator to them.
> Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
> -----------------------------------------------------------------------------------------
>
> Key: CDI-371
> URL: https://issues.jboss.org/browse/CDI-371
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.PFD
> Reporter: John Ament
>
> In CDI spec, section 6.7.1 message-driven beans are included as having Request Scope enabled during invocation. This is not consistent with other areas where MDBs were removed. Further more this section needs additional review with the updated MDB spec that the EJB group has come up with.
> I believe Transaction Scope is more appropriate.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-205) Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-205?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-205:
--------------------------------
Actually we spoke about this at JUDcon two years ago (activation of the context).
Let's continue over in CDI-371
> Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-205
> URL: https://issues.jboss.org/browse/CDI-205
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> *7.2. Container invocations and interception* states:
> When the container invokes a method of a bean, the invocation may or may not be treated as a business method invocation:
> * Invocations of message listener methods of message-driven beans during message delivery are business method invocations.
> As MDBs are not CDI beans their methods shouldn't be business invocations (and thus should not pass through method interceptors and decorators).
> If the original intent was to support such use case the spec should be reworded.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-205) Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-205?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-205:
-------------------------------
Why? That has come totally out of nowhere (and I think you are totally wrong).
> Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-205
> URL: https://issues.jboss.org/browse/CDI-205
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> *7.2. Container invocations and interception* states:
> When the container invokes a method of a bean, the invocation may or may not be treated as a business method invocation:
> * Invocations of message listener methods of message-driven beans during message delivery are business method invocations.
> As MDBs are not CDI beans their methods shouldn't be business invocations (and thus should not pass through method interceptors and decorators).
> If the original intent was to support such use case the spec should be reworded.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-371) Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
by John Ament (JIRA)
John Ament created CDI-371:
------------------------------
Summary: Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
Key: CDI-371
URL: https://issues.jboss.org/browse/CDI-371
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.1.PFD, 1.0
Reporter: John Ament
In CDI spec, section 6.7.1 message-driven beans are included as having Request Scope enabled during invocation. This is not consistent with other areas where MDBs were removed. Further more this section needs additional review with the updated MDB spec that the EJB group has come up with.
I believe Transaction Scope is more appropriate.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-205) Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-205?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-205:
--------------------------------
Thanks Pete.
I fear that this has been missed then, as section 6.7.1 should have had some kind of update applied to reflect a similar change.
> Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-205
> URL: https://issues.jboss.org/browse/CDI-205
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> *7.2. Container invocations and interception* states:
> When the container invokes a method of a bean, the invocation may or may not be treated as a business method invocation:
> * Invocations of message listener methods of message-driven beans during message delivery are business method invocations.
> As MDBs are not CDI beans their methods shouldn't be business invocations (and thus should not pass through method interceptors and decorators).
> If the original intent was to support such use case the spec should be reworded.
--
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
11 years, 10 months
Improve debugging support for class-based proxies - supported by CDI or CDI implementations?
by Jens Schumann
Hi all!
With the advent of class-based proxies my team and I have been fooled by debuggers quite often. To be honest I don't want to know how many hours we wasted so far while looking at the attributes of an proxy wondering why the application behaved differently (based on what the attributes of that proxy said ;). Even experienced developers usually need some time to detect that the attribute they are looking at are the default values of the class and not the values of the target instance.
Therefore I am wondering if we could help IDE providers to detect such situations and provide useful hints to developers. At a minimum I would ask for a simple "this is not the real instance"-hint, best case the debugger shows the values of the target instance. Some time ago I asked the IDEA guys (1) for better class-based proxy support in their debugger, nevertheless it would remain a proprietary solution once implemented.
I am not an expert in that field, but here are my thoughts.
- Across all bytecode manipulation/ bytecode generation frameworks there is no common way to detect whether a given object instance is a proxy or not.
- There is no direct JVM/java class library support either, apart from Class.isSynthetic – see 4.7.6 The Synthetic Attribute in (2)
- A debugger could simply rely on Class.isSynthetic to show a simple hint (if all CDI implementations would set this attribute – see 3)
- We could ensure that proxies implement a common CDI SPI interface that allows access to the target instance. (If it wouldn't take that long the interface should be part of java.lang.reflect or similar).
What do you think?
Jens
(1) http://youtrack.jetbrains.com/issue/IDEA-88756
(2) http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html
(3) https://issues.jboss.org/browse/WELD-1417
11 years, 10 months
[JBoss JIRA] (CDI-205) Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-205?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-205:
--------------------------------
Did the URL for this pull change?
Looks like this wasn't removed from section 6.7.1
> Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-205
> URL: https://issues.jboss.org/browse/CDI-205
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> *7.2. Container invocations and interception* states:
> When the container invokes a method of a bean, the invocation may or may not be treated as a business method invocation:
> * Invocations of message listener methods of message-driven beans during message delivery are business method invocations.
> As MDBs are not CDI beans their methods shouldn't be business invocations (and thus should not pass through method interceptors and decorators).
> If the original intent was to support such use case the spec should be reworded.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-370:
--------------------------------
The difference here is that JMS explicitly notes the activation of the context. WebSocket spec makes no reference to any of the CDI contexts.
> Expand @RequestScoped and @SessionScoped to account for WebSocket
> -----------------------------------------------------------------
>
> Key: CDI-370
> URL: https://issues.jboss.org/browse/CDI-370
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Joseph Snyder
>
> We've been testing injection into a WebSocket endpoint.
> @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope.
> However if you try to use the injected object from within the @OnMessage callback you get a Weld error:
> SEVERE: org.jboss.weld.context.ContextNotActiveException:
> WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
> Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback?
--
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
11 years, 10 months
[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann edited comment on CDI-370 at 5/7/13 8:20 AM:
-----------------------------------------------------------
While the current CDI spec maintains a strong relationship between RequestScoped and HTTP i would not assume that RequestScoped is strictly bound to HTTP. The RequestScope spec/javadoc lists 4 use cases with one being bound to HTTP and another one that may hint a dependency to HTTP (because of JAX-RS, JAX-WS doesn't require HTTP). Especially it's availability in EJB method invocations and @PostConstruct tells me: RequestScopes lives without HTTP just perfectly.
So RequestScoped should be available for WebSocket message delivery similar to the current JMS/@Asynchronous support.
Personally I believe the sections "6.7.x \{scope\} context lifecycle" are already too verbose. I have no profound knowledge of the Java EE specification process, nevertheless I believe the scope lifecycle should be better covered by the Java EE umbrella spec similar to security and transactions (Java Platform, Enterprise Edition (Java EE) Specification, v7 and later). This way you can expanded the supported platform specs without touching the CDI spec again.
Same applies to "2.4.1 Built-in scope types". The current wording "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7 represent the standard scopes defined by the Java Servlets specification." does not cover all supported use cases in 6.7.x and should relaxed (in a CDI 1.1 maintenance release i guess).
was (Author: french_c):
While the current CDI spec maintains a strong relationship between RequestScoped and HTTP i would not assume that RequestScoped is strictly bound to HTTP. The RequestScope spec/javadoc lists 4 use cases with one being bound to HTTP and another one that may hint a dependency to HTTP (because of JAX-RS, JAX-WS doesn't require HTTP). Especially the availability in EJB method invocations and @PostConstruct tells me: RequestScopes lives without HTTP just perfectly.
So RequestScoped should be available for WebSocket message delivery similar to the current JMS/@Asynchronous support.
Personally I believe the sections "6.7.x {scope} context lifecycle" are already too verbose. I have no profound knowledge of the Java EE specification process, nevertheless I believe the scope lifecycle should be better covered by the Java EE umbrella spec similar to security and transactions (Java Platform, Enterprise Edition (Java EE) Specification, v7 and later). This way you can expanded the supported platform specs without touching the CDI spec again.
Same applies to "2.4.1 Built-in scope types". The current wording "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7 represent the standard scopes defined by the Java Servlets specification." does not cover all supported use cases in 6.7.x and should relaxed (in a CDI 1.1 maintenance release i guess).
> Expand @RequestScoped and @SessionScoped to account for WebSocket
> -----------------------------------------------------------------
>
> Key: CDI-370
> URL: https://issues.jboss.org/browse/CDI-370
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Joseph Snyder
>
> We've been testing injection into a WebSocket endpoint.
> @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope.
> However if you try to use the injected object from within the @OnMessage callback you get a Weld error:
> SEVERE: org.jboss.weld.context.ContextNotActiveException:
> WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
> Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback?
--
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
11 years, 10 months