Thanks for the email. All of the scopes currently reuse the
implementation from core, which are all backed by the
AbstractThreadLocalMapContext. New threads must still be created by the
application, but the app can then apply scopes to those threads as it
sees fit (starting and stropping sessions, requests and conversations).
None of this is set in stone though.
I'm not 100% sure that I want session scope to be thread-local. I think
that's assuming too much about the target application. On the other
hand, if that's Servlet works then it may be confusing to go against
that pattern. Have to think about it. Thoughts anyone?
On Mon, 2009-04-13 at 14:53 -0300, Marcell Manfrin Barbacena wrote:
> Hi Pete,
> What do you mean by session and conversation scopes in the SE context?
> Are they separated by different threads?
> Ty. Nice docs. Haven't see the code but I hope to do it today or tomorrow.
> On Fri, Apr 10, 2009 at 8:12 PM, Peter Royle
> <howardmoon(a)screamingcoder.com> wrote:
> > Hi,
> > I have added some documentation for SE. It doesn't yet include any of
> > the threading/shutdown manager stuff, and I've got a little TODO in
> > there. Can anyone tell me, does the Interceptor/decorator stuff make use
> > of any EE features, or will it probably work out of the box in SE? I
> > just haven't got round to trying yet.
> > I've also checked in a Swing version of the number guess example at
> > webbeans/examples/trunk/se/number-guess.
> > Finally, I'm /experimenting/ with enabling and using Request, Session
> > and Conversation scopes/contexts in SE. If you're interested in seeing
> > the working code I've got the changes to core, SE and the number guess
> > example ready to check in to separate branches. Happy to discuss this
> > further if anyone is interested/curious.
> > Cheers,
> > Pete.
> > _______________________________________________
> > webbeans-dev mailing list
> > webbeans-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/webbeans-dev
In 3.2.1 the spec says that @Entity/orm.xml entities aren't simple
beans. I think that this requirement should be adjusted to be a bit
more generic and say that any classes defined as entities by your JPA
provider aren't simple beans. This seems more consistent with the idea
- why would @Entity classes not be simple beans but e.g. .hbm.xml
classes be simple beans?
I've done some changes to the test harness
* tidy up property names for controlling harness
* rename properties file so it's not web-beans-tck :-)
* extract generic server management code (so I can write a connector
to run tests in tomcat)
I've tested it quite well, but I'm sure I missed a properties file
somewhere, so, if you find an odd error in running the testsuite,
please poke around or ping me :-)