[weld-dev] Maintenance release

[Mark Struberg]

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 at redhat.com> wrote:

> From: Pete Muir <pmuir at redhat.com>
> Subject: Re: [weld-dev] Maintenance release
> To: "Mark Struberg" <struberg at yahoo.de>
> Cc: "Java Community Process JSR #299 Expert List" <JSR-299-EG at jcp.org>, "Weld-Dev" <weld-dev at lists.jboss.org>, "Gavin King" <gavin.king at 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?