[cdi-dev] Hierarchy of ManageableContext and Context

[Emily Jiang]

+1 on creating a separate interface. If ManagedContext is not a context, I 
agree with Martin to give it a different name. How about ManagableState 
etc?

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     cdi-dev at lists.jboss.org, 
Date:   19/07/2016 08:28
Subject:        Re: [cdi-dev] Hierarchy of ManageableContext and Context
Sent by:        cdi-dev-bounces at lists.jboss.org



Hi John,

I don't see a problem if we introduce a ManageableContext interface 
(with activate/deactivate) and a custom context implements it. In other 
words, I don't think it has to be used only for built-in contexts.

Also the context definition is clear (6.2. The Context interface) and 
again, if these are two different things then we should not call it a 
context at all [1].

Martin

[1]
https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823


Dne 18.7.2016 v 13:19 John D. Ament napsal(a):
> All,
>
> I'm starting a discussion thread outside of the PR to avoid folks on the
> EG not receiving github notifications.  I want to drive to get the
> opinions of the broader EG and use this as feedback on whether or not we
> change the hierarchy.
>
> I've been against having ManageableContext (MC) extend
> Context/AlterableContext (AC).  There's a few reasons.  First,
> semantically I can register a context, but I shouldn't be able to
> register a MC.  That means from an inheritance standpoint MC does not
> pass the is-a check on AC.  MC may be a composition style, or nothing at
> all since it may not be associated to any specific thread in the
> future.  While we can put in spec verbiage and exceptions to cover the
> cases where someone does implement MC and try to register it,
> realistically if it's there as a compilation time option, I shouldn't
> get an error if it passes.
>
> I can agree that the bulk of the methods on MC should match AC.  That's
> where I introduced a new base class for the two and had MC extend that.
> The base class provided no behavior, just method signatures.  The second
> key thing for me is in this area.  AC is more like a definition, where
> as MC is a running instance of that definition.  Since these are
> different, it shows that MC doesn't inherit the use-case of the parent 
AC.
>
> Third issue I have with extending is that AC is meant to be implemented
> by developers to create custom contexts.  Developers aren't intended to
> implement MC.  The container should provide these instances, since they
> are intended only for built in contexts.  We allow developers who
> implement AC to control their activation, as a result we've already
> provided a means to disassociate a custom AC from any thread.
>
> I want to get others opinions on whether these reasons make sense and if
> they guide to the same conclusion about not extending AC.  For what its
> worth, I've shown these classes to some of  my own developers to get
> their feedback, who have had to do things like quartz integration or
> responding to netty requests and activate contexts.  The concerns I
> raise are based on questions they've asked me.
>
> John
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.
>
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160719/920034bd/attachment.html