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 >>>> >>>> >> >>
