dev@jsr311.java.net

Re: JSR311: taking the POJO injection idea further

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 19 Feb 2008 16:06:17 -0500

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 ;-).

>> GET http://host.com/customerdb/;first=Bill;last=Burke;ssn=444-44-4444
>> @Path("/customerdb/{customerid}")
>> @GET
>> public String get(@MatrixParam("first") String firstName,
>> @MatrixParam("last") String lastName, ...) {...}
>
> Your method declaration starts to get REALLY long. What if I need a
> few Pathparam, header params or even cookie params? Gets even
> longer if I want @DefaultValues
>
True, hence UriInfo, HttpHeaders etc.

>
>> or
>> @Path("/customerdb/{customerid}")
>> @GET
>> public String get() {
>> CustomerPK c = new CustomerPK(uriInfo.getMatrixParameters());
>> ...
>> }
>
> Well, there is no uriInfo.getMatrixParameters() and get() needs an
> @HttpContext UriInfo.

My bad, I was thinking of uriInfo.getQueryParameters.

> Let's see what's simpler though:
>
> public String get(@PathParam("customerid") CustomerPK pk) {
> }
>
> public class CustomerPK {
> @MatrixParam String first;
> @MatrixParam String last;
> @MatrixParam int ssn;
> }
>
> vs.
>
> public String get(@PathParam("customerid") PathSegment segment) {
> CustomerPK pk = new CustomerPK(segment.getMatrixParameters());
> }
>
> public class CustomerPK {
>
> public CustomerPK(MultivaluedMap<String, String> matrix) {
> first = matrix.getFirst("first");
> last = matrix.getFirst("last");
> ssn = Integer.valueOf(matrix.getFirst("ssn"));
> }
> }
>
> 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.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.