[JBoss JIRA] Updated: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-80:
-------------------------
Fix Version/s: 1.1 (Confirmed)
(was: 1.1 (Proposed))
Git Pull Request: https://github.com/jboss/cdi/pull/42 (was: https://github.com/jboss/cdi/pull/42)
Forum Reference: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio... (was: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio...)
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Assigned: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir reassigned CDI-80:
----------------------------
Assignee: Pete Muir
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Updated: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-80:
-------------------------
Git Pull Request: https://github.com/jboss/cdi/pull/42
Forum Reference: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio... (was: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio...)
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Commented: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-80:
------------------------------
https://github.com/jboss/cdi/pull/42
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
Fwd: Enum injection
by Lincoln Baxter
--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter(a)redhat.com
"If you want something, you'll find a way; if you don't, you'll find an excuse."
----- Forwarded Message -----
From: "Lincoln Baxter" <lbaxter(a)redhat.com>
To: "Pete Muir" <pmuir(a)redhat.com>
Sent: Tuesday, September 6, 2011 11:11:26 AM
Subject: Re: [cdi-dev] Enum injection
I think that because Enums are not "Classes" they have been excluded. If you look at Brian's issue, I believe this doesn't work in Weld. Maybe it's just a bug, but in any case, the spec is not clear on the issue.
--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter(a)redhat.com
"If you want something, you'll find a way; if you don't, you'll find an excuse."
----- Original Message -----
From: "Pete Muir" <pmuir(a)redhat.com>
To: "Lincoln Baxter" <lbaxter(a)redhat.com>
Sent: Tuesday, September 6, 2011 10:28:40 AM
Subject: Re: [cdi-dev] Enum injection
I believe enums in Bean Archives should be scanned today actually, can you see anything in the spec that stops this?
On 6 Sep 2011, at 15:23, Lincoln Baxter wrote:
> Wow, I'm glad to see this issue has been addressed. I didn't originally intend this issue to mean injection into Enums, but I'm sure there's some strange use for that.
>
> I would be happy with scanning enums for annotations alone, but if we want to support injection as well, I think field and method injection (for things like observer methods and method initializers) makes a lot of sense.
>
> Interesting, you've effectively defined a new language for injectable singletons with this change. That has interesting potential.
>
> --
> Lincoln Baxter, III
> JBoss, by Red Hat
> lbaxter(a)redhat.com
>
> "If you want something, you'll find a way; if you don't, you'll find an excuse."
>
> ----- Original Message -----
> From: "Pete Muir" <pmuir(a)redhat.com>
> To: "CDI-Dev" <cdi-dev(a)lists.jboss.org>
> Sent: Monday, September 5, 2011 1:06:27 PM
> Subject: [cdi-dev] Enum injection
>
> I've written up the spec changes for https://issues.jboss.org/browse/CDI-127 as https://github.com/jboss/cdi/pull/37 - please review :-)
>
> There is an open question here. Currently I've defined it as being non-portable to inject into an enum defined in a shared library, as the behavior when injecting contextual instances becomes complex (as this is essentially static injection). Please let me know if this is going to cause a problem for you.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
12 years, 7 months
[JBoss JIRA] Created: (CDI-148) Conversation Scope should be as available as Request Scope (Ubuquitous), and not tied to JSF
by Lincoln Baxter III (JIRA)
Conversation Scope should be as available as Request Scope (Ubuquitous), and not tied to JSF
--------------------------------------------------------------------------------------------
Key: CDI-148
URL: https://issues.jboss.org/browse/CDI-148
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.0
Reporter: Lincoln Baxter III
In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from *after* RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
For instance:
* User has custom PhaseListener for *Before* RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
* In said PhaseListener, user attempts to access a ConversationScoped bean.
* ContextNotActiveException results, even though there may be a valid CID in the Request URL
Example 2:
* User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
* ContextNotActiveException results, this just doesn't work!
There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Updated: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-80:
-------------------------
Description:
In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
For instance:
User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
In said PhaseListener, user attempts to access a ConversationScoped bean.
ContextNotActiveException results, even though there may be a valid CID in the Request URL
Example 2:
User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
ContextNotActiveException results, this just doesn't work!
There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
Forum Reference: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio... (was: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-Conversatio...)
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
Application lifecycle events
by Pete Muir
I've created a pull request for https://issues.jboss.org/browse/CDI-86 at https://github.com/jboss/cdi/pull/39.
This adds these events:
• @Initialized @Application Object o;
• @Destroyed @Application Object o;
• @Initialized @Session Object o;
• @Destroyed @Session Object o;
• @Initialized @Conversation Object o;
• @Destroyed @Conversation Object o;
• @Initialized @Request Object o;
• @Destroyed @Request Object o;
The actual event type depends on why the context was initialized (e.g. if it's a web app you would normally see the relevant servlet event objects). More details in the pull
There are a few open issues on which I appreciate feedback:
* The CDI 1.0 spec doesn't define when a context is "initialized" (however the concept is implied), however the CDI spec introduces lifecycle events that require an event to be fired when a context is initialized. Either we need to rewrite the definition of this feature to use the CDI 1.0 language or we need to define when a context is initialized.
* What should the event type be for requests initialized due to an EJB remote invocation and a JMS MessageListener invocation?
* What should the event type be for applications initialized or destroyed when the application is not a web app?
* The annotations for context lifecycle events are in the new package javax.enterprise.context.lifecycle. Should they be placed elsewhere (especially if we envision them being used for other purposes than context lifecycle events?)
12 years, 7 months
[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
See also CDI-112
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Closed: (CDI-136) Assumption all @Stateful beans should be passivation capable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
Pete Muir closed CDI-136.
-------------------------
Resolution: Done
Change made. Tests will be updated in CDI 1.1.
> Assumption all @Stateful beans should be passivation capable
> ------------------------------------------------------------
>
> Key: CDI-136
> URL: https://issues.jboss.org/browse/CDI-136
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Java EE integration
> Affects Versions: 1.0
> Reporter: David Blevins
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope.
> Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix.
> Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified.
> The user should be able to say if they want passivation validation on their stateful bean and dependencies.
> We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation.
> From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months