<font size=2 face="sans-serif">+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?</font>
<br>
<br><font size=2 face="sans-serif">Many thanks,<br>
Emily<br>
===========================<br>
Emily Jiang<br>
WebSphere Application Server, CDI Development Lead</font>
<br><font size=2 face="sans-serif"> <br>
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN<br>
Phone: +44 (0)1962 816278 Internal: 246278<br>
<br>
Email: emijiang@uk.ibm.com <br>
Lotus Notes: Emily Jiang/UK/IBM@IBMGB<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Martin Kouba <mkouba@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">cdi-dev@lists.jboss.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">19/07/2016 08:28</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [cdi-dev]
Hierarchy of ManageableContext and Context</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cdi-dev-bounces@lists.jboss.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi John,<br>
<br>
I don't see a problem if we introduce a ManageableContext interface <br>
(with activate/deactivate) and a custom context implements it. In other
<br>
words, I don't think it has to be used only for built-in contexts.<br>
<br>
Also the context definition is clear (6.2. The Context interface) and <br>
again, if these are two different things then we should not call it a <br>
context at all [1].<br>
<br>
Martin<br>
<br>
[1]<br>
</font></tt><a href="https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823"><tt><font size=2>https://github.com/cdi-spec/cdi/pull/296#issuecomment-229942823</font></tt></a><tt><font size=2><br>
<br>
<br>
Dne 18.7.2016 v 13:19 John D. Ament napsal(a):<br>
> All,<br>
><br>
> I'm starting a discussion thread outside of the PR to avoid folks
on the<br>
> EG not receiving github notifications. I want to drive to get
the<br>
> opinions of the broader EG and use this as feedback on whether or
not we<br>
> change the hierarchy.<br>
><br>
> I've been against having ManageableContext (MC) extend<br>
> Context/AlterableContext (AC). There's a few reasons. First,<br>
> semantically I can register a context, but I shouldn't be able to<br>
> register a MC. That means from an inheritance standpoint MC
does not<br>
> pass the is-a check on AC. MC may be a composition style, or
nothing at<br>
> all since it may not be associated to any specific thread in the<br>
> future. While we can put in spec verbiage and exceptions to
cover the<br>
> cases where someone does implement MC and try to register it,<br>
> realistically if it's there as a compilation time option, I shouldn't<br>
> get an error if it passes.<br>
><br>
> I can agree that the bulk of the methods on MC should match AC. That's<br>
> where I introduced a new base class for the two and had MC extend
that.<br>
> The base class provided no behavior, just method signatures. The
second<br>
> key thing for me is in this area. AC is more like a definition,
where<br>
> as MC is a running instance of that definition. Since these
are<br>
> different, it shows that MC doesn't inherit the use-case of the parent
AC.<br>
><br>
> Third issue I have with extending is that AC is meant to be implemented<br>
> by developers to create custom contexts. Developers aren't intended
to<br>
> implement MC. The container should provide these instances,
since they<br>
> are intended only for built in contexts. We allow developers
who<br>
> implement AC to control their activation, as a result we've already<br>
> provided a means to disassociate a custom AC from any thread.<br>
><br>
> I want to get others opinions on whether these reasons make sense
and if<br>
> they guide to the same conclusion about not extending AC. For
what its<br>
> worth, I've shown these classes to some of my own developers
to get<br>
> their feedback, who have had to do things like quartz integration
or<br>
> responding to netty requests and activate contexts. The concerns
I<br>
> raise are based on questions they've asked me.<br>
><br>
> John<br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> cdi-dev@lists.jboss.org<br>
> </font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
><br>
> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
><br>
_______________________________________________<br>
cdi-dev mailing list<br>
cdi-dev@lists.jboss.org<br>
</font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
<br>
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
<br>
</font></tt>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>