[cdi-dev] Hierarchy of ManageableContext and Context

John D. Ament john.d.ament at gmail.com
Mon Jul 18 07:19:08 EDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160718/6360f2e9/attachment.html 


More information about the cdi-dev mailing list