Ps: we can reuse a custom handler instead of rewriting a proxy factory with asm
@PartialBean of deltaspike is more or less the same feature (with scope handling for handler) Le 21 sept. 2013 22:56, "Romain Manni-Bucau" <[email protected]> a écrit : > Works for me > Le 21 sept. 2013 22:51, "David Blevins" <[email protected]> a > écrit : > >> My phrasing might have been off -- I was agreeing with you on all points >> :) I was just thinking about how we'd implement it. >> >> We can't instantiate an abstract class so we'd still have to generate a >> subclass and implement the methods for the developer as we do now. But >> definitely, we could have all sorts of techniques for implementing the >> method. One of which could be to just throw an AbstractMethodError >> (perhaps that's what @AbstractAllowed could imply). >> >> Another could be to use @Handler on the abstract method and we'd make >> that method delegate to the handler. The @AbstractAllowed could really >> just be a meta-annotation of >> @Handler(org.apache.openejb.AbstractMethodErrorHandler.class) or something. >> >> We could allow people to specify these on the bean class or the abstract >> method itself. If it's not on the method, we use the bean class default. >> >> >> -David >> >> On Sep 21, 2013, at 1:13 PM, Romain Manni-Bucau <[email protected]> >> wrote: >> >> > the point is if a method is abstract the bean doesn't know how to impl >> it >> > so why should it impl it? an indirection looks mandatory here >> > >> > *Romain Manni-Bucau* >> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > *Blog: **http://rmannibucau.wordpress.com/*< >> http://rmannibucau.wordpress.com/> >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > *Github: https://github.com/rmannibucau* >> > >> > >> > >> > 2013/9/21 David Blevins <[email protected]> >> > >> >> To allow for partial implementation we'd still have to subclass and >> >> implement the abstract methods to do something. >> >> >> >> So either they delegate to some other method like >> InvocationHandler.invoke >> >> or we implement them to throw a RuntimeException or Error like >> >> AbstractMethodError. >> >> >> >> If someone wanted them to throw AbstractMethodError, they could >> implement >> >> their InvocationHandler.invoke to throw it. We could definitely make >> an >> >> annotation that implies this is the behavior someone wants. >> >> >> >> In fact, we could have annotations that imply how an abstract method >> >> should be handled and allow people to use them either on the bean >> class or >> >> the individual method. >> >> >> >> >> >> -David >> >> >> >> On Sep 21, 2013, at 11:19 AM, Romain Manni-Bucau < >> [email protected]> >> >> wrote: >> >> >> >>> wouldn't it be more relevant to replace it by interceptors? = allow >> >>> abstract ejb if an interceptor intercepts them. >> >>> >> >>> the ejb would have @AbstractAllowed and the interceptor @Handle or >> sthg >> >>> like that >> >>> >> >>> *Romain Manni-Bucau* >> >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> >>> *Blog: **http://rmannibucau.wordpress.com/*< >> >> http://rmannibucau.wordpress.com/> >> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> >>> *Github: https://github.com/rmannibucau* >> >>> >> >>> >> >>> >> >>> 2013/9/21 David Blevins <[email protected]> >> >>> >> >>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau < >> [email protected]> >> >>>> wrote: >> >>>> >> >>>>> I think we already have it through cdi and decorators but it doesnt >> >> hurt >> >>>> to >> >>>>> get it this way ;). >> >>>> >> >>>> Similar to decorators, yes. Just as the @Proxy+InvocationHandler >> >> concept >> >>>> is similar to interceptors. >> >>>> >> >>>> Big difference in both from their decorator/interceptor equivalent is >> >> that >> >>>> with those you'd still be required to have concrete bean class. Sort >> >> of a >> >>>> downer if you never actually want it to be called. >> >>>> >> >>>>> Fun feature allowing partial impl btw! >> >>>> >> >>>> Exactly! And interestingly enough, since it's a subclass and the >> >> subclass >> >>>> *is* the actual class instantiated, even "this" invocations to >> abstract >> >>>> methods will go to the invoke(..) method. >> >>>> >> >>>> >> >>>> -David >> >>>> >> >>>> >> >> >> >> >> >>
