Looks good, though I think we shouldn't have session or request
here (just conversation and application)
I can certainly see the benefits of not having to worry about Request
and Session scopes for standalone desktop apps.
There were 2 main reasons I chose to include Request and Session though:
- Primarily for applications other than standalone desktop apps which
happen to have multiple user support and/or are server based, but no
HTTP/Servlet based front-end. For example a Trading platform using FIX
protocol. This almost makes me think that non Servlet scopes belong in a
separate extension - something that could be used in conjunction with
EJB Lite. Thinking aloud a bit there.
- Secondarily, it made it easier to implement Conversation, which uses
those two scopes in the existing implementation.
What are your thoughts on these?
Yes, I need to finish the lifeycle SPI stuff, I got the idea straight
My idea is that lifecycle just has methods to do the relevant things
here, and you don't need to worry about things like conversation
Let me do this work (will be the week after next I think), and then we
> I would like to clean up the syntax for starting requests
> obviously pretty ugly and verbose right now. Maybe some kind of
> annotation and interceptor pair perhaps? And possibly some
> Swing-specific helpers to make it easy to attach the Request context
> a button click? Making this sort of stuff more transparent is my next
I guess, as hinted above, probably doing away with Request and Session
scope, or somehow making it completely transparent at least is the way
forward here. Agree?
> Let me know what you think, anyone. Cheers.
>>> Finally, I'm /experimenting/ with enabling and using Request,
>>> and Conversation scopes/contexts in SE. If you're interested in
>>> the working code I've got the changes to core, SE and the number
>>> example ready to check in to separate branches. Happy to discuss
>>> further if anyone is interested/curious.
>> Perhaps send a patch out for review (or attach to a JIRA issue?)
>>> webbeans-dev mailing list
>> Pete Muir