Closed pgelinas closed 10 years ago
Sure, no problem. My goal was to provide a sensible first draft of the idea. Really, all I did was inspire myself with what was done for generator: the ObjectIdGenerator
API and its default implementation are part of the annotation project, so it made sense to me to put ObjectIdResolver
and default implementation (ie keep current behaviour) there.
With regards to typing: I might have been a bit lazy with ObjectIdResolver
. It started off with it being generic, but I had some compilation error and generics warning here and there, so I scratched that and made it handle Object
. I might do a second pass if you wish and see if I can make it generic, so that it could be more strongly typed.
Understood. I am not sure I can actually figure out better ways; and the point about ObjectIdGenerator
is good -- it is also deviation from ideal.
So in all likelihood I think this is the way to go, but I will go through code once more just in case. Besides, we can still re-factor, 2.4 won't be quite ready in very near future.
Actually I think this is fine, will merge.
Ok, makes sense. I think we need to talk about code organization -- ideally annotation package would not contain implementation classes. In this case it is bit tricky, wrt defaulting and such.
One possible alternate would be to move
ObjectIdResolver
(and base implementation) intojackson-databind
, and changing type of resolver annotation to beClass<Object>
. This in turn would allow resolver itself to be more strongly typed. Defaulting is bit tricky however... could useNoClass.class
, and letAnnotationIntrospector
handle it.But I am not sure what would be optimal here -- I'll have to think about this bit more.