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 <gudnabr...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
