Interesting. Currently it reuses the @LocalBean code.
-David On Sep 21, 2013, at 1:59 PM, Romain Manni-Bucau <[email protected]> wrote: > 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 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>>
