Romain Manni-Bucau wrote:
right
the question here is do we want to use it or not internally (cdi-query was
based on it no? and i think it avoid to repeat too much code, we could
handle the annotation indirection you speak about to be clearer in APIs)
if we dont' want to use it, it can wait CDI-110 otherwise we can push it
now (maybe take servicehandler code but removing javassist?)
Javassist was only used so that we could support abstract classes as
well. I think this is a useful feature, but I agree that the javassist
dependency is problematic.
Something that has been on my list to do for quite a while is write a
single class ProxyFactory with no outside dependencies, that can just be
copied or shaded into whatever project needs it.
Stuart
i'm still not very clear about DS and its CDI targets: saw CDI 1.0 is a
target so maybe we should address it even if CDI 1.1 answer later to this
question...i'm not very concerned about it but it should be taken into
account i think
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/14 Stuart Douglas<sdoug...@redhat.com>
I suppose it depends on if
https://issues.jboss.org/**browse/CDI-110<https://issues.jboss.org/browse/CDI-110>makes
it into the specification.
This sounds equivalent to the solder @ServiceHandler annotation, although
@ServiceHandler has another layer of indirection, so you do not need to
specify the implementation class directly on the bean.
I think this is a useful feature.
Stuart
Romain Manni-Bucau wrote:
Hi,
wonder if we want the "already bridged proxy feature" (i'll explain don't
worry ;)).
There are cases where the implementation is boring and pretty obvious and
defining an interface has the benefit to creates a semantic but the
implementation itself is pretty useless (ex: spring-data, cdi-query, ...)
We can of course do "as usually" and create proxy for all features needing
it specifically.
However i think this proxy feature is generic enough and could be pushed
to
the user if he wants to do so.
Here some functional cases i think about which could use this feature:
1) (already cited) a cdi-query like
2) accessing JMX information (locally or not) without needed to use JMX
API
(
http://svn.apache.org/repos/**asf/openejb/trunk/openejb/**
examples/dynamic-proxy-to-**access-mbean/src/test/java/**
org/superbiz/dynamic/mbean/**DynamicMBeanClient.java<http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/dynamic-proxy-to-access-mbean/src/test/java/org/superbiz/dynamic/mbean/DynamicMBeanClient.java>
for
instance)
3) creating a rest api easily from method name (getUserList -> GET
/user/list for instance)
4) ....
it can go further allowing multiple handlers by interface
wdyt?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
*
