[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-408:
-------------------------------------
Fix Version/s: 1.2
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
> Key: CDI-408
> URL: https://issues.jboss.org/browse/CDI-408
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Reporter: Jens Schumann
> Fix For: 1.2
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>
> Btw: Which JIRA version is CDI 1.1 Final?
--
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
10 years, 4 months
[JBoss JIRA] (CDI-388) Session bean specialization example is not valid
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-388?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-388:
-------------------------------------
Fix Version/s: 1.2
> Session bean specialization example is not valid
> ------------------------------------------------
>
> Key: CDI-388
> URL: https://issues.jboss.org/browse/CDI-388
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Martin Kouba
> Fix For: 1.2
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.
--
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
10 years, 4 months
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-411:
-------------------------------------
Labels: Investigate (was: )
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
> Key: CDI-411
> URL: https://issues.jboss.org/browse/CDI-411
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Labels: Investigate
> Fix For: 1.2
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.
--
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
10 years, 4 months
[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-370:
----------------------------------------
Assignee: Antoine Sabot-Durand
> 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
> Assignee: Antoine Sabot-Durand
>
> 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
10 years, 4 months
[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-370:
------------------------------------------
It’s the responsibility of Websocket spec to implement these scopes. We should ensure they take the point before closing the ticket.
> 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
> Assignee: Antoine Sabot-Durand
>
> 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
10 years, 4 months
[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-370:
-------------------------------------
Labels: (was: cdi-1.1-mr investigate)
> 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
10 years, 4 months
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-411:
-------------------------------------
Labels: cdi-1.1-mr investigate (was: cdi-1.1-mr)
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
> Key: CDI-411
> URL: https://issues.jboss.org/browse/CDI-411
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Labels: cdi-1.1-mr, investigate
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.
--
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
10 years, 4 months
[JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-395.
--------------------------------------
Resolution: Rejected
Resolving this could bring more problems (with backward compatibility) that it could solve.
Implementations are encouraged to give a warning when it's detected in the code.
> Public fields in extensions should not be allowed
> -------------------------------------------------
>
> Key: CDI-395
> URL: https://issues.jboss.org/browse/CDI-395
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans.
> The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors.
> See also WELD-1474
--
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
10 years, 4 months
[JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-395:
-------------------------------------
Labels: (was: cdi-1.1-mr investigate)
> Public fields in extensions should not be allowed
> -------------------------------------------------
>
> Key: CDI-395
> URL: https://issues.jboss.org/browse/CDI-395
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans.
> The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors.
> See also WELD-1474
--
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
10 years, 4 months
FW: Producer wrapper
by Arne Limburg
I guess, this mail was meant to go to the list ;-)
Von: Romain Manni-Bucau <rmannibucau(a)gmail.com<mailto:rmannibucau@gmail.com>>
Datum: Montag, 16. Dezember 2013 12:50
An: Arne Limburg <arne.limburg(a)openknowledge.de<mailto:arne.limburg@openknowledge.de>>
Betreff: Re: [cdi-dev] Producer wrapper
I think the main issue is to avoid to make extensions hard/long to write (already too complicated for common stuff IMO) so i dont like this solution.
It is great to have a clean design...it is better to have something usable. CDI needs to work on the last quickly IMO before adding any feature.
Le 16 déc. 2013 12:38, "Arne Limburg" <arne.limburg(a)openknowledge.de<mailto:arne.limburg@openknowledge.de>> a écrit :
Hi,
A simple solution to this topic would be to state in the spec, that, if an
extension replaces an InjectionTarget or Producer it MUST provide a custom
Implementation of an ObserverMethod for every private observer method of
that bean.
WDYT? Maybe we should discuss this in the meeting this evening?
Regards,
Arne
Am 12.12.13 16:23 schrieb "Mark Struberg" unter <struberg(a)yahoo.de<mailto:struberg@yahoo.de>>:
>
>1. Producer / InjectionTarget might create instances which are wrapped in
>proxies.
>
>2. event observer methods are allowed to be private and thus are not in
>the proxies.
>
>3. extensions are allowed to 'decorate' InjectionTargets and Producers.
>
>
>This means that we need some unwrap method in the spec, right?
>Currently this does not York.
>
>LieGrue,
>strub
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
>https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
10 years, 4 months