deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: @Proxy
Date Fri, 14 Sep 2012 00:01:50 GMT
Inline

On Thu, Sep 13, 2012 at 5:08 PM, Romain Manni-Bucau
<rmannibucau@gmail.com>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?)
>
> 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


DeltaSpike (as can be seen in our CI builds) targets current CDI 1.0
implementations and also being forward compatible with CDI 1.1 (as I
believe Weld is the only one currently with a CDI 1.1 branch, could be
wrong though).


> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/9/14 Stuart Douglas <sdouglas@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>
> >> *
> >>
> >>
>



-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message