Hi Pete!
Yes, being a fan of the 'real world objects' paradigma, I assumed that
'context' and 'Context' (the interface) really means the same kind of
granularity. The section 6.7 imho mixes the lifecycle of the Context with the lifecycle of
the Contextual beans it manages.
It's a simple wording issue, maybe we can make this more clear in the MR.
And of course, our AfterBeanDiscoveryEvent#addContext() also adds exactly one Context to
the BeanManager ;)
(But for built-in scopes wo do not use this, but maintain the Contextx via a
ContextFactory).
LieGrue,
strub
--- On Mon, 1/11/10, Pete Muir <pmuir(a)redhat.com> wrote:
From: Pete Muir <pmuir(a)redhat.com>
Subject: Re: [weld-dev] Maintenance release
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org>,
"Weld-Dev" <weld-dev(a)lists.jboss.org>, "Gavin King"
<gavin.king(a)gmail.com>
Date: Monday, January 11, 2010, 3:23 PM
On 10 Jan 2010, at 21:36, Mark Struberg wrote:
> Hi Gavin!
>
> A few random observations from a non-native english
speaker, so beg your pardon if I got something wrong ;)
>
> Clarifying the 'Context' lifespan:
>
> I think it is currently not clear what a Context
instance represents.
>
> While the wording in the default scope lifecycle
section (6.7) suggests that there are n (multiple) Context
objects for a specific Scope annotation [1] (e.g. one
SessionContext instance for each session), the system
eventing section (11.5.2) [2] only allows adding a single
Context for a Scope annotation (kind of a Context-Facade?).
>
> [1] 6.7.2
> The session context is shared between all servlet
requests that occur _in_the_same_HTTP_session (->another
session gets another session context?). The session context
is destroyed when the HTTPSession times out, after all
HttpSessionListeners have been called, and at the very end
of any request in which invalidate() was called, after all
filters and ServletRequestListeners have been called
(->again backs the n-contexts theory).
I think you are inserting the word "instance" into these
sentences in your head when you read them - if you re read
6.7.2 "The session context is provided by a built-in context
object" you can see the spec does differentiate between the
concept of the "session context" (multiple contexts per
application instance) and the "context object for the
session" (one instance per application instance). Perhaps
there is a way to clean up the language to make it clearer
that there is expected to only be one context object
instance?
>
>
> [2] 11.5.2
> AfterBeanDiscovery#addContext() registers a custom
Context object with the container.
> (-> no way to add a 'ContextFactory')
>
>
> While this doesn't make much difference for our built
in scopes (e.g. OWB currently implements the n-context
strategy with a ContextFactory while weld seems to use 1
SessionContext instance, isn't?) it may make a difference
for portable extensions. And it is really confusing for
people who only want to write an extension providing a
Context for a custom scope.
So how do you implement addContext() in OWB? Surely it is
tricky as it involves cloning the object?