commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [proxy] 2.0 WAS Re: a bit of commons-style code in search of a home
Date Thu, 15 Jul 2010 03:07:48 GMT

On Jul 14, 2010, at 9:15 PM, James Carman wrote:

> 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
> 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

I believe that's the code I originally pulled in [lang] for  
TypeUtils.  However, since the latest contributions I've merged, the  
[lang] one now far surpasses the handling in [proxy].  So I know the  
recording is there, but I hadn't tracked down exactly how you were  
using it yet.  I suspect there are still some cool ideas we can  
borrow from Mockito.  I'll respond to your other thread as well.


> a bit of TLC tonight.
> On Wed, Jul 14, 2010 at 7:01 PM, Matt Benson <>  
> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message