You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2013/09/21 12:48:22 UTC
TOMEE-1040 - Abstract Dynamic Beans
Implemented an experimental feature in the spirit of the @Proxy concept where an interface can be given along with an InvocationHandler implementation.
When the bean is created we'd create the InvocationHandler, create a proxy using the interface, then use the proxy as the bean instance.
Took this idea a bit further to allow for abstract classes to get the same perk and more. If the bean class is abstract and implements java.lang.reflect.InvocationHandler, then the abstract methods will delegate to the bean's java.lang.reflect.InvocationHandler.invoke(..) method.
This allows for sort of a hybrid approach where some methods can be abstract and handled in a reflection-like manner, while others can be implemented regularly.
An interesting difference is the code takes extreme care to implement all the constructors of the parent class as well as the annotations of the parent class and any method annotations and method param annotations of abstract methods.
This should allow the dynamically created class to replace the parent class in every way, including usage in annotation heavy APIs like JAX-RS, JAX-WS or CDI. I tested JAX-RS and it seems to work perfectly.
For example see this RESTful service:
@Stateless
@Path("/ejb")
public abstract class RESTIsVeryCool implements InvocationHandler {
@EJB
private SimpleEJB simpleEJB;
@javax.ws.rs.core.Context
Request request;
@Path("/normal")
@GET
public abstract String normal();
@Path("/rest")
@GET
public abstract String rest();
@Path("/param")
@GET
public String param(@QueryParam("arg") @DefaultValue("true") String p) {
return p;
}
@Path("/field")
@GET
public boolean field() {
return "GET".equals(request.getMethod());
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
return simpleEJB.ok();
}
}
This is of course an experiment. All sorts of feedback welcome! We can go anywhere or nowhere with this :)
-David
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
It doesnt works on abtract classes IIRC.
Le 23 sept. 2013 04:28, "David Blevins" <da...@gmail.com> 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 <rm...@gmail.com>
> 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" <da...@gmail.com> a
> écrit :
> >
> >> Interesting.
> >>
> >> Currently it reuses the @LocalBean code.
> >>
> >>
> >> -David
> >>
> >> On Sep 21, 2013, at 1:59 PM, Romain Manni-Bucau <rm...@gmail.com>
> >> 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" <rm...@gmail.com> a
> >>> écrit :
> >>>
> >>>> Works for me
> >>>> Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <
> rmannibucau@gmail.com
> >>>
> >>>>> 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 <da...@gmail.com>
> >>>>>>
> >>>>>>> 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 <
> >>>>> rmannibucau@gmail.com>
> >>>>>>> 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 <da...@gmail.com>
> >>>>>>>>
> >>>>>>>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>
> >>
>
>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by David Blevins <da...@gmail.com>.
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 <rm...@gmail.com> 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" <da...@gmail.com> a écrit :
>
>> Interesting.
>>
>> Currently it reuses the @LocalBean code.
>>
>>
>> -David
>>
>> On Sep 21, 2013, at 1:59 PM, Romain Manni-Bucau <rm...@gmail.com>
>> 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" <rm...@gmail.com> a
>>> écrit :
>>>
>>>> Works for me
>>>> Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <rmannibucau@gmail.com
>>>
>>>>> 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 <da...@gmail.com>
>>>>>>
>>>>>>> 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 <
>>>>> rmannibucau@gmail.com>
>>>>>>> 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 <da...@gmail.com>
>>>>>>>>
>>>>>>>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>
>>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <da...@gmail.com> a écrit :
> Interesting.
>
> Currently it reuses the @LocalBean code.
>
>
> -David
>
> On Sep 21, 2013, at 1:59 PM, Romain Manni-Bucau <rm...@gmail.com>
> 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" <rm...@gmail.com> a
> > écrit :
> >
> >> Works for me
> >> Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <rmannibucau@gmail.com
> >
> >>> 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 <da...@gmail.com>
> >>>>
> >>>>> 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 <
> >>> rmannibucau@gmail.com>
> >>>>> 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 <da...@gmail.com>
> >>>>>>
> >>>>>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com>
> >>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
>
>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by David Blevins <da...@gmail.com>.
Interesting.
Currently it reuses the @LocalBean code.
-David
On Sep 21, 2013, at 1:59 PM, Romain Manni-Bucau <rm...@gmail.com> 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" <rm...@gmail.com> a
> écrit :
>
>> Works for me
>> Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <rm...@gmail.com>
>>> 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 <da...@gmail.com>
>>>>
>>>>> 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 <
>>> rmannibucau@gmail.com>
>>>>> 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 <da...@gmail.com>
>>>>>>
>>>>>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <rm...@gmail.com> a
écrit :
> Works for me
> Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <rm...@gmail.com>
>> 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 <da...@gmail.com>
>> >
>> >> 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 <
>> rmannibucau@gmail.com>
>> >> 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 <da...@gmail.com>
>> >>>
>> >>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> >>>> 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
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Works for me
Le 21 sept. 2013 22:51, "David Blevins" <da...@gmail.com> 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 <rm...@gmail.com>
> 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 <da...@gmail.com>
> >
> >> 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 <rmannibucau@gmail.com
> >
> >> 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 <da...@gmail.com>
> >>>
> >>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>>> 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
> >>>>
> >>>>
> >>
> >>
>
>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by David Blevins <da...@gmail.com>.
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 <rm...@gmail.com> 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 <da...@gmail.com>
>
>> 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 <rm...@gmail.com>
>> 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 <da...@gmail.com>
>>>
>>>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <rm...@gmail.com>
>>>> 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
>>>>
>>>>
>>
>>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <da...@gmail.com>
> 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 <rm...@gmail.com>
> 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 <da...@gmail.com>
> >
> >> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <rm...@gmail.com>
> >> 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
> >>
> >>
>
>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by David Blevins <da...@gmail.com>.
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 <rm...@gmail.com> 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 <da...@gmail.com>
>
>> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <rm...@gmail.com>
>> 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
>>
>>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <da...@gmail.com>
> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <rm...@gmail.com>
> 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
>
>
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by David Blevins <da...@gmail.com>.
On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <rm...@gmail.com> 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
Re: TOMEE-1040 - Abstract Dynamic Beans
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi great!
I think we already have it through cdi and decorators but it doesnt hurt to
get it this way ;). Fun feature allowing partial impl btw!
Le 21 sept. 2013 12:49, "David Blevins" <da...@gmail.com> a écrit :
> Implemented an experimental feature in the spirit of the @Proxy concept
> where an interface can be given along with an InvocationHandler
> implementation.
>
> When the bean is created we'd create the InvocationHandler, create a proxy
> using the interface, then use the proxy as the bean instance.
>
> Took this idea a bit further to allow for abstract classes to get the same
> perk and more. If the bean class is abstract and implements
> java.lang.reflect.InvocationHandler, then the abstract methods will
> delegate to the bean's java.lang.reflect.InvocationHandler.invoke(..)
> method.
>
> This allows for sort of a hybrid approach where some methods can be
> abstract and handled in a reflection-like manner, while others can be
> implemented regularly.
>
> An interesting difference is the code takes extreme care to implement all
> the constructors of the parent class as well as the annotations of the
> parent class and any method annotations and method param annotations of
> abstract methods.
>
> This should allow the dynamically created class to replace the parent
> class in every way, including usage in annotation heavy APIs like JAX-RS,
> JAX-WS or CDI. I tested JAX-RS and it seems to work perfectly.
>
> For example see this RESTful service:
>
> @Stateless
> @Path("/ejb")
> public abstract class RESTIsVeryCool implements InvocationHandler {
>
> @EJB
> private SimpleEJB simpleEJB;
>
> @javax.ws.rs.core.Context
> Request request;
>
> @Path("/normal")
> @GET
> public abstract String normal();
>
> @Path("/rest")
> @GET
> public abstract String rest();
>
> @Path("/param")
> @GET
> public String param(@QueryParam("arg") @DefaultValue("true")
> String p) {
> return p;
> }
>
> @Path("/field")
> @GET
> public boolean field() {
> return "GET".equals(request.getMethod());
> }
>
> @Override
> public Object invoke(Object proxy, Method method, Object[] args)
> throws Throwable {
> return simpleEJB.ok();
> }
> }
>
>
> This is of course an experiment. All sorts of feedback welcome! We can
> go anywhere or nowhere with this :)
>
>
> -David
>
>