To be honest I'm not sure if I'd do any of this. All this should imo not belong to
the EE spec at all. It is probably just far too business specific.
What if the application needs some kind of role change. E.g. you temporarily switch roles,
change the preferred language, etc? All these things are heavily depending on the
application and are not technical at all.
LieGrue,
strub
On Monday, 22 December 2014, 20:12, arjan tijms <arjan.tijms(a)gmail.com> wrote:
Hi,
On Monday, December 22, 2014, Antonio Goncalves <antonio.goncalves(a)gmail.com>
wrote:
Hi all,
>
>
>
>The CDI spec defines the "Transactional observer methods" (ยง10.4.5) with a
TransactionPhase :
>
>
>public enum TransactionPhase {
> IN_PROGRESS,
> BEFORE_COMPLETION,
> AFTER_COMPLETION,
> AFTER_FAILURE,
> AFTER_SUCCESS
>}
>
>
>void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated Document doc) { ... }
>
>
>
>
>Now that there is a new Security specification coming along, it would be helpful to be
able to observe before/after the user logs-in or logs-out, for example. First I thought
"well, the Security spec defines a set of events, fires them, and we just have to
observe them". But what about the "during" phase ? What would make more
sense in such use case ? Using the same "during" mechanism or events ?
I think separate events may be better.
Maybe I'm mistaken but the way I think the transactional events are used is that
during a transactional method an event is fired. The event is then not delivered right
away to all observers, but for those using during=after_success only when the TX commits.
This is kinda like what JMS does; a message is only send when the TX commits, or send
right away. CDI offers 3 other cases, but I feel that those first two are the main ones.
For authentication events I don't think we can really speak of a
"logging-in" method. Even if we would appoint one (e.g. validateRequest() in a
SAM) then I'm not sure whether any random event published during that method would
have any need to be queued until just before or after authentication actually happens.
Instead, we would merely be interested in the actual events; the moment the container is
about to authenticate (so we can potentially veto) and the moment right after that (so we
can take an action such as loading data related to the user into the current session).
Just my 2 cents. Hope I understood the case correctly.
Kind regards,
Arjan
>
>public enum LoginPhase {
> BEFORE_LOGIN,
> AFTER_LOGIN,
> BEFORE_LOGOUT,
> AFTER_LOGOUT,
>}
>
>
>void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ... }
>
>
>
>
>Any thoughts ?
>
>--
>
>Antonio Goncalves
>Software architect, Java Champion and Pluralsight author
>
>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.