It doesnt works on abtract classes IIRC. Le 23 sept. 2013 04:28, "David Blevins" <[email protected]> a écrit :
> 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >> > >> > >
