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