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