Re: JSR311: taking the POJO injection idea further

From: Bill Burke <>
Date: Tue, 19 Feb 2008 17:24:37 -0500

Bill Burke wrote:
> Marc Hadley wrote:
>> On Feb 19, 2008, at 2:56 PM, Bill Burke wrote:
>>> Marc Hadley wrote:
>>>> On Feb 19, 2008, at 1:15 PM, Bill Burke wrote:
>>>>> I just showed you an example where IAGNI, so I fail to see your point.
>>>> Your example could easily be covered by the existing stuff we have:
>>> Then why do we have @HeaderParam or @QueryParam? or even Providers?
>>> They could be built easily using Httpheaders, UriInfo, and
>>> InputStream respectively. i.e.
>> Taken to its logical conclusion why do we even bother with Java,
>> everyone should just write bytecode directly ;-).
> You're missing my point. @HeaderParam and @QueryParam only save one
> line of Java code, so why have them? Cuz they are convenience functions
> and make the code more readable. Same with the java bean mappings I'm
> suggesting.
>>> You're not saving a crazy alot of code here, but you are saving some,
>>> and it looks more readable. These savings can be compounded if you
>>> start reusing these mapped pojos in different methods and resources.
>> Thinking aloud, an alternative might be to allow an unannotated method
>> parameter even for HTTP methods that don't have an entity body. Then
>> you could have a custom message body reader conjur up the bean from
>> whatever combination of request information is appropriate. That would
>> let you write:
>> @GET
>> public String get(CustomerPK pk) {
>> }
>> public class CustomerPK {
>> String first;
>> String last;
>> int ssn;
>> }
>> Not sure I like that, I think the current mapping from entity body to
>> parameter is quite natural and this might confuse that.
> I think that alternative should be allowed too. It really depends on
> whether you want to decouple your mappings or not. Providers decouple,
> annotations couple. Coupling isn't also a bad thing. You sould be
> aware of the distributed protocol. You can always delegate to business
> logic.

Also, having to write a Provider for something that could be easily
mapped seems too complicated.

Bill Burke
JBoss, a division of Red Hat