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(a)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.

From: "Martin Kouba" <mkouba(a)redhat.com&gt; To: cdi-dev(a)lists.jboss.org Sent: Tuesday, July 19, 2016 9:26:25 AM Subject: Re: [cdi-dev] Hierarchy of ManageableContext and Context 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(a)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(a)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.