[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
14 years, 11 months
EL namespaces
by Pete Muir
Hi all,
On the JSR-341 (EL.next) we've been discussing making bean namespacing a first class feature.
Currently the proposal on the table from JSR-341 is that the built in conversation bean would be referenced by #{N(javax.enterprise.context).conversation}. This is obviously a deviation from the syntax that CDI 1.0 has used (#{javax.enterprise.context.conversation}) but does remove the ambiguity between property/method access and namespacing that is inherent in the CDI 1.0 option.
I would propose that the CDI 1.1 spec is updated to recommend this approach, and that the old approach is deprecated for CDI 1.1 (but still required to work). We can then address in CDI 1.1.next whether we want to remove the 1.0 approach, or keep it for backwards compatibility.
Below is the thread on which we discussed this, including some ideas on how to implement the old approach on top of the new EL namespace support.
Any concerns?
Pete
Begin forwarded message:
> From: Kin-man Chung <kinman.chung(a)oracle.com>
> Date: 12 August 2011 19:24:16 GMT+01:00
> To: jsr341-experts(a)el-spec.java.net
> Subject: [jsr341-experts] Re: Bean names with namespace
> Reply-To: jsr341-experts(a)el-spec.java.net
>
> On 08/12/11 10:29, Pete Muir wrote:
>> Sorry for the late reply.
>>
>> On 9 Aug 2011, at 21:25, Kin-man Chung wrote:
>>
>>
>>> On 08/09/11 12:03, Pete Muir wrote:
>>>
>>>> On 9 Aug 2011, at 18:02, Kin-man Chung wrote:
>>>>
>>>>
>>>>
>>>>> I recall that it is a CDI requirement that bean names can have namespaces, such as "org.goofy.configs". Pete, is this still the case?
>>>>>
>>>>>
>>>> Yes. This is in the CDI spec, so can't be removed right away, we need to support this for at least the next revision.
>>>>
>>>>
>>>>
>>> I am curious about how it got in the CDI spec in the first place? It is just a little strange that CDI can write into its spec about some functionalities in another spec that is currently not supported, to say the least.
>>>
>> Sure. CDI doesn't require UEL to support namespaced beans generally, however it does require that:
>>
>> * CDI beans can have names which include namespaces as above
>> * CDI beans with names are resolvable by UEL
>>
>> So I don't *think* CDI is specifying a UEL feature, but simply specifying it's own features and integrations.
>>
>>
> Thanks for clarifying this.
>
> Still, if UEL was consulted before this was put in the CDI spec, it would have been apparent that it's not a good idea to introduce such ambiguities, and that another syntax would have been used. Of course I understand that UEL has not been active for a long time, to say the least, and CDI probably just want to move forward. :-)
>
>>>
>>>>> Are there any other things that EL needs to do, other than the ability to parse and evaluates it?
>>>>>
>>>>>
>>>> No.
>>>>
>>>>
>>>>
>>>>> Since names that contains a "." creates ambiguities are parse time, we'll need to resolve it. I propose that we introduce another syntax notation for it, like what we did for static fields. For instance, we can write
>>>>>
>>>>> #{N(org.goofy.configs).memSize}.
>>>>>
>>>>> to denote the bean org.goofy.configs with the property memSize. What do you think?
>>>>>
>>>>>
>>>> This wouldn't work for CDI due to backwards compatibility.
>>>>
>>>>
>>>>
>>> What backwards compatibility? It is not working currently! Did you really got it to work with EL 2.2? How?
>>>
>> Yes it works with UEL 2.2. As we know at deployment time all the bean names, including namespaces, we can create synthetic objects for each node in the namespace hierarchy needed. For example we would create an "org" object, with a "goofy" child object (and perhaps a "jboss" child object were org.jboss.plmuir.Foo a bean we have as well). When "org" is passed to our namespace EL resolver, we return this org synthetic object. This is then passed in as the base when "goofy" is the property to resolve, and we return the Goofy object (and so on). If we don't have a namespace object, of course we return null.
>>
>> Then, in our bean resolver, if the base is a namespace object, we can cast to it, and simply call a method on it to retrieve the fully-qualified namespace, concatenate the current property name, and do a bean lookup.
>>
>>
>>> What I like about the N() notation is that it is easy on the parser as well as on the user. It provides a visual indication about what the expression does. In general, it is just not a good language design to contain ambiguities that cannot be easily resolved.
>>>
>> Understood.
>>
>>
>>>
>>>> Instead (or as well?), could we offer a registerNamespace() method (similar to how we are handling imports)? Then EL will have a static list of namespaces that an (optional?) namespace resolver could resolve against before other resolvers are used. CDI knows namespaces at startup so could register all it needs.
>>>>
>>>> WDYT?
>>>>
>>> If we have to support it without any syntax aid, we'll need to have something like registerNamespace(). I am not sure how and when the information can be best used. Ideally, we'd like to be able to recognize the namespaces early, at parse time, so that we don't need to change how it works at evaluation, so ELResolvers may not be the right solution. Even at the parse time, it'll require either a deep look-ahead or backtracking. Also, a simple typo can produce errors that are hard to track down.
>>>
>>> Can CDI deprecate the current namespace support in favor of the N() notation?
>>>
>> Yes, I can make it "optional" in 1.1 I guess, introduce the N() notation and then we can remove it in CDI 1.1+1.
>>
>>
> Can you make sure that CDI EGs are OK with this? Thanks.
>
>> I'm not wedded to the syntax, just looking for the best solution all around.
>>
>>
> I also don't like having to introduce another reserved word. But since we have already introduced T(), a N() is not too bad. Of course if you have other ideas, we'll be glad to consider them.
>
>>> Can CDI implementation provides a tools to turn #{org.goofy.configs.memSize} into #{N(org.goofy.configs).memSize}?
>>>
>> I guess, because we know the namespaces up front, we can simply check if org.goofy.configs is a registered namespace, and if it is, rewrite the EL expression. Does that sound reasonable?
> Yes, it is. Of course this is just a suggestion for a way to implement namespace in CDI, taking advantage of the new N() syntax in EL, so that the complicated hack with ELResolvers would not necessary.
>
> Thanks. I am really glad that we've arrived at a solution acceptable to all of us! :-)
>
> Kin-man
14 years, 11 months
Standardization on a query like qualifier/annotation
by John D. Ament
Hey gents (&lasses, if any exist on the list)
I wanted to raise a question on something I'm working on for the JMS 2.0
EG. JMS has a MessageSelector feature that allows a client to control what
messages come in to the client consumer. I'm wondering how possible it
would be to standardize on a query selector type of annotation, where
attributes are evaluated compared to values. The idea would be to limit
what observer methods get hit based on matches in this query selector
annotation. Here's an example:
public void observeSomeObjects(@Observes @MessageSelector("loaded = true")
MyBean mb) {
...
}
where:
public class MyBean {
@JmsProperty
private boolean loaded;
@JmsPayload
private String data;
//getters and setters...
}
so when the loaded property is true, and an event is fired, then this
observer is called. however, when false, this observer is not invoked.
>From thinking about it a bit, I was thinking that an Interceptor should do
it, but wanted to get your opinions if it was something that could be
standardized (potentially in CDI 1.1) rather than specific to JMS.
Opinions? Comments?
Thanks,
John
14 years, 11 months
Interceptors for qualified @PostConstruct methods?
by Craig Ringer
Hi all
I've been running into a few cases where it'd be rather handy to be able
to add handling of @PostConstruct (and to a lesser extent @PreDestroy)
to a CDI interceptor, so I can run code before/after a @PostConstruct
method is invoked.
My specific use case is PrettyFaces, where I'd like to be able to
perform additional injection into a class before @PostConstruct is run.
URL query parameters are to be injected when a bean is constructed,
before @PostConstruct is called. PrettyFaces currently uses an action
method that's run at every request instead, but this works poorly for
beans that are of scopes other than @RequestScoped and requires some
hacks to use effectively.
It's possible that this particular use case can be solved using a
portable extension. PrettyFaces could add new Bean instances with a
prettyfaces-specific qualifier, then app classes can use that qualifier
on injection sites. Parameters not passed may be injected as null; the
injected objects would be of dependent scope so that should be OK. I'm
not sure that'll work yet, though, and I thought it'd be worth raising
the idea of intercepting @PostConstruct and @PreDestroy anyway, in case
that sets off ideas for others.
Opinions? Is this a reasonable thing to want? Any obvious pitfalls or
downsides to adding support for it?
--
Craig Ringer
15 years