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
