myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: MyFaces Fusion Naming
Date Fri, 02 Mar 2007 19:06:33 GMT
On 3/2/07, Mario Ivankovits <> wrote:
> Hi Craig!
> > One thing I've wondered as I've watched the fusion stuff go by ... in
> > an architecture that is so heavily based on Spring 2 already, why
> > wasn't Spring Web Flow used?
> Don't know much about SWF, but we had a meeting with Jürgen Höller from
> interface21 where he helped designing the integration of the
> conversation scope with Spring including the persistence stuff.
> If SWF would have been possible to do this he would have said it.

You're right ... he would definitely know :-).

> Also Fusion do depend on Spring 2, but not that hard ... for sure, it
> uses its possibility to create custom scopes and makes use of their
> persistence framework, though, its still modular enough that - if JSF
> will ever allow custom scopes - it can be plugged in there too.

My personal feeling is this should really be solved at the servlet spec level.

> What might be possible is, that SWF make use of this new scope too -
> Fusion is also designed in a way that you can replace the web framework
> (in the important area).
> Maybe (I hope for the future) shale-dialog can make use of this scope
> too, and can provide a solution for the persistence that way.

That's where I don't understand Fusion enough to comment ... it
originally appeared to me that the key value add was allocating the
entity manager on the way in (when you created the conversation), and
cleaning up afterwards when the conversation ended.  That much is
really easy to do with pretty much any conversation scope API (for
example, with Shale you'd just define a listener that was notified
about the start and stop events; with Struts 2 you'd stick this logic
into an interceptor chain, and so on).  I guess that I don't
understand why supporting the persistence manager that way *required*
a new kind of conversation paradigm.

It's more of academic interest to me at the moment (I'm buried in work
stuff right now) ... but if your conversation scope stuff can be
adapted to Shale Dialog's dialog manager[1] APIs[2], it'd be pretty
easy to integrate -- there's already two implementations (basic and
SCXML based), so the more the merrier.



> Ciao,
> Mario

View raw message