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