commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [proxy] 2.0 WAS Re: a bit of commons-style code in search of a home
Date Thu, 15 Jul 2010 02:15:36 GMT
Well, the proxy code needs a bit of work.  First, I'd say, I need to
rollback the serializability requirement for all generated proxies.
It's easy enough to make your proxies serializable if you just add
java.io.Serializable to the list of classes/interfaces you want
proxied (I'll put in a test case for that).  Next, we could add some
simple genericized methods that only take one class/interface and
return exactly that type.  I have actually already implemented the
"recorder" functionality you speak of.  I just have to remember where
it is at the moment!  I think I'm going to download proxy and give it
a bit of TLC tonight.

On Wed, Jul 14, 2010 at 7:01 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
> James,
>  What's the status of the genericized proxy 2.0 branch?  I think the code I talked
about yesterday is basically a fancy way to describe building an Interceptor.  So proxy might
be a good home for it.  It's not really limited to annotations anyway, though I could see
providing a subclass configured to do sane things for annotation proxies.
>
> -Matt
>
> On Jul 13, 2010, at 6:10 PM, Matt Benson wrote:
>
>> Hi all,
>>  I've been getting friendly with the Bean Validation (bval) podling camp of late,
and one of the requirements of implementors of JSR303 is that they generate annotation instances
on the fly.  In practice this means proxying interfaces.  It's a foregone conclusion that
a JSR303 implementation must do this by virtue of their being required to treat XML-defined
constraints more or less indistinguishably from constraints expressed via code annotations,
and the specification group chose the annotation to be the lowest common denominator as far
as validation constraints are concerned.
>>
>>  Now, obviously there are lots of ways to generate these runtime proxies, and we
even have a [proxy] component.  bval already has mechanisms in place to accomplish their
XML-to-annotation requirements as far as implementing the JSR303 spec is concerned.  However,
recently the Hibernate-Validator project, which is the RI of the spec, released their 4.1.0
version, which contained support for the idea of fluent builders for these constraints.  The
logical next step for javax.validation providers is to explore dynamic application of constraints
so this was bound to happen.  However, their current implementation requires the values of
a custom annotation's methods be set either using a custom-written helper class, or referring
to methods by name.  Each approach has its drawbacks (the former requiring extra developer
involvement; the latter lacking type-safety).
>>
>>  Over the past year or so, I've become a big fan of the Mockito library which manages
to allow you to stub out  the behavior of your mock objects using a mechanism that, by recording
actual method invocations on a mock object, stays completely typesafe as you specify your
result objects.  It occurred to me that something like this would perfectly satisfy my wishes
for type-safety without requiring an ancillary class to handle a given annotation.  Having
gotten past the hard part (the idea itself) I now have an implementation-agnostic API for
setting up annotation proxies fluently and with type-safety, as well as a working implementation
of this API.  Note that neither the API nor the implementation are in any way restricted
to javax.validation annotations.
>>
>>  I expect this to be a fairly useful type of component as annotations become a larger
and larger part of day-to-day Java programming, and for that reason would be happy for it
to live in Commons.  I *don't* know that this is large enough to be a component on its own.
 On the other hand, because my initial implementation is backed by Mockito itself I am somewhat
hesitant to add this to e.g. [lang].  I wonder if any other Commons devs have any thoughts
or advice on what I should do with this thing now that I've written it.
>>
>> Thanks for reading,
>> Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message