Sounds like it could work -- at least for cases where people want to have methods that are just for decoration or interception.
I've seen it demoed with interfaces. That work for abstract classes as well? (I'd suppose so). -David On Sep 21, 2013, at 11:42 PM, Romain Manni-Bucau <[email protected]> wrote: > Maybe stupid but let suppose we have java 7 (i know for certification but > as tomcat did for last release and websockets i think we can get some j7 > only features): what about defaults on interfaces? If all methods of a > @Local or @Remote have a default then we dont need the impl > Le 22 sept. 2013 00:25, "David Blevins" <[email protected]> a écrit : > >> 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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >> >>
