[cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods

Sun Feb 14 02:43:30 EST 2016

Le 14 févr. 2016 00:04, "Mark Struberg" <struberg at yahoo.de> a écrit :
>
> > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau at gmail.com
>:
> >
> > You can also extend 3rd party classes - no producer but same constraint
- so needs to be global - ie not limited to producers - or doesnt help.
>
> I also think it should be an option which is not only required for
producer methods but more generic. Also extending a 3rd party class in a
bean archive creates this restriction.
>
> @David:
> that comes pretty close to my original proposal to have a @AllowProxying
anntation on the producer field/method or managed bean. I like Pete’s last
comment and we of course could also simply rename this to
@ContainsNonBusinessMethods or something similar. It would avoid the term
‚proxy‘ which some people seem to think is too low level. But I thin that
not many user would grasp what that does in the end. It’s not as
self-explaining as @AllowProxying imo.
> We probably would also need to extend the SPI in that case to allow
Extensions to have full control.
>
> One more thing:
> This also hits already existing apps which move from Java6 to 7/8. I’m
fine with supporting those on a non-portable basis.
>

If in a SPI we can probably accept to write a custom "migration" Extension
then. Important is to not touch existing codebase.

> @John
> > The gotcha that I still see is around interceptor bindings.  They need
to be explicitly disallowed on final methods, and big ole warning put in
when you have interceptors on classes with final methods.
> That could be a good thing to do. Of course it only is possible if the
interceptor is applied on a method and not on the whole class. In the later
case the final methods would simply not work on the proxy.
>
>
> LieGrue,
> strub
>
>
> > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau at gmail.com
>:
> >
> > You can also extend 3rd party classes - no producer but same constraint
- so needs to be global - ie not limited to producers - or doesnt help.
> >
> > Le 13 févr. 2016 23:25, "John D. Ament" <john.d.ament at gmail.com> a
écrit :
> > Some comments in line.
> >
> > On Sat, Feb 13, 2016 at 4:22 PM David Blevins <david.blevins at gmail.com>
wrote:
> > Read what I could get my hands on.  Unfortunately the JIRA itself has
36 comments which won’t load/expand in Safari or Chrome.  But I think I get
the summary.
> >
> > Sounds like a not too responsive UI.  I wonder if Atlassian has a test
for 36 comments. XD
> >
> >
> > High level, I agree with both Mark and Martin.
> >
> >  - Agree with Mark: Where I see this feature being important is in our
EJB/CDI alignment efforts.  This appears to be the rare case where the CDI
spec is more strict than the EJB spec and a speed bump in someone’s efforts
to port an EJB application to CDI.  For that reason, this to me upgrades
from nice-to-have to we-must-find-a-way.
> >
> > Yep, and in thinking about past jobs have run into the issue.  People
don't read every line of a spec, and don't always understand why something
stopped working.
> >
> >
> >  - Agree with Martin: I also strongly dislike the use of beans.xml in
any fashion and system properties even more.  Aside from being cumbersome
for users, I’m particularly against setting a trend of using system
properties to bail us out of hard API design issues.  This concern trumps
the above and I would -1 this vote as-is.
> >
> > That said, I’m not sure if this approach is workable in any way, but
here goes:
> >
> > We keep the default rule of beans with final methods being unproxyable
unless explicit action in code is taken and the class is:
> >
> >    - explicitly produced via @Produces
> >    - added explicitly via an extension
> >
> > I don't see a reason that the bean manager needs to ignore classes with
final methods.  More-so, I don't see the strategy as being comprehensible
to the typical developer that they need a producer.  Sure, for 3PL's you're
probably already creating a producer.  For cases where I just made my class
with a final method, I shouldn't be penalized.
> >
> > Less boilerplate, that's one of the goals right?  If so, I don't see
why we can't just deal with a final method in a proxy - don't extend it.
> >
> > The gotcha that I still see is around interceptor bindings.  They need
to be explicitly disallowed on final methods, and big ole warning put in
when you have interceptors on classes with final methods.
> >
> >
> > Effectively the BeanManager would continue to ignore beans with final
methods as proxyable in a classpath scan, but the application could “go
back” and explicitly put them into the BeanManager as proxyable.
> >
> >
> > Thoughts?  Big holes in there?
> >
> >
> > -David
> >
> >
> >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:
> >>
> >> Hi Guys,
> >>
> >> Some EG members (like David Blevins) asked to have until the ned of
the week-end to vote here.
> >> I find interesting to have the more possible input but as the rules
were to end the vote tonight, I wanted to be sure that nobody has any
objection for closing the vote on sunday 11:59pm CET.
> >>
> >> Regards,
> >>
> >> Antoine
> >>
> >> Le ven. 12 févr. 2016 à 17:23, Mark Struberg <struberg at yahoo.de> a
écrit :
> >> Sure, that might probably be a viable way to do it.
> >>
> >> Oki, here are the two use cases which we need to solve:
> >>
> >> 1.)
> >> @Produces
> >> @ApplicationScoped
> >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …};
> >>
> >> 2.)
> >> @ApplicationSCoped
> >> public class MySubclass extends
SomeWeirdThirdPartyClassWithFinalMethods {}
> >>
> >> Any other use case?
> >>
> >> Can you please elaborate how your idea will look like? Just a few
ideas so we can get it running.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >> PS: Again: I’m NOT interested to get my approach in. All I’m
interested in is a _solution_ for this real world problem. But there was
simply no alternative proposed so far…
> >>
> >>
> >>
> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir at redhat.com>:
> >> >
> >> > -1
> >> >
> >> > The problem seems real, but proposed approach doesn't sit right with
> >> > me. I think it would be better to follow the EJB approach, and add a
> >> > way to be able to declare a method as "not a business method" (a
> >> > business method is also a thing in CDI IIRC).
> >> >
> >> > For example, e.g. using beans.xml and an annotation. This then allows
> >> > the spec to consistently treat this public method as not a business
> >> > method.
> >> >
> >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand
> >> > <antoine at sabot-durand.net> wrote:
> >> >> Hi all,
> >> >>
> >> >> There have been a lot of discussion around CDI-527 in the last
weeks:
> >> >> https://issues.jboss.org/browse/CDI-527
> >> >>
> >> >> Mark proposed a PR:
> >> >> https://github.com/cdi-spec/cdi/pull/271
> >> >>
> >> >> But we don't agree on adding this feature to the spec.
> >> >> This vote is to decide if we should add this feature at the spec
level now,
> >> >> or not.
> >> >> Should we vote this feature down, that won't mean it will be
completely
> >> >> dropped: it could be implemented as non portable feature in both
Spec or
> >> >> even be included as experimental feature in the spec (in annexes) as
> >> >> describe in the PR comments
> >> >> Vote starts now, only vote from EG members are binding (but you can
give
> >> >> your opinion if not part of the EG) and will last 72 hours.
> >> >>
> >> >> You vote with the following values:
> >> >> +1 : I'm favorable for adding this feature in the spec
> >> >> -1 : I'm against adding this feature in the spec
> >> >> 0 : I don't care
> >> >>
> >> >> Thank you for your attention and your vote.
> >> >>
> >> >> Antoine Sabot-Durand
> >> >>
> >> >> _______________________________________________
> >> >> 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.
> >>
> >> _______________________________________________
> >> 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.
> >
> > _______________________________________________
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160214/ce07da16/attachment.html 