[cdi-dev] Hierarchy of ManageableContext and Context
Matej Novotny
manovotn at redhat.com
Tue Jul 19 08:14:23 EDT 2016
Hi all,
here are my two cents on this (pretty much covered that in the PR comments, just didn't get much attention there):
* I am also standing behind the idea to keep ManageableContext (MC) in the current hierarchy. It should extend AlterableContext and obviously we will need to add activate/deactivate methods there.
** In short... Yes, I see this as a _Context_ :)
* As an entry point, BeanManager seems a good way.
** BM.getContext() can stay as it is now, therefore we won't break any compatibility. It will return the running context, throw exception otherwise
** We should add BM.getManageableContext (or something along those lines) which will give you an instance of ManageableContext which you can then activate
* As for people implementing this on their own (and registering via extension which was the argument against it)
** There might not really be any harm in it; or at least I see none, though I may be missing something
** And if you feel otherwise, we might still change the doc and say that this is forbidden
** Again, such doc change will not cause any backward compatibility because there are not apps which would have it now.
Matej
----- Original Message -----
> From: "Martin Kouba" <mkouba at redhat.com>
> To: cdi-dev at 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 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.
>
More information about the cdi-dev
mailing list