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]
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.