Validating a PathParam

4,553 views
Skip to first unread message

Roy Jacobs

unread,
Nov 18, 2013, 4:52:03 PM11/18/13
to dropwiz...@googlegroups.com
This must be such an obvious question, but here goes: If I have a @PathParam, I can't seem to put any validators on it.

As an example, this doesn't seem to work:
@POST
@Path("/{myParam}")
public Response doFoo(@PathParam("myParam") @Size(max=32) String myParam { /* ... */ }

Ofcourse I can do the validation myself, but I get the feeling I'm doing some trivial thing wrong...any ideas?

Roy

Coda Hale

unread,
Nov 18, 2013, 8:21:20 PM11/18/13
to dropwiz...@googlegroups.com
You can use regular expressions to limit a path:

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

signature.asc

Roy Jacobs

unread,
Nov 19, 2013, 3:56:07 AM11/19/13
to dropwiz...@googlegroups.com
Thanks. I was aware of this, but an invalid path (e.g. if the param is too long) would cause a 404, which is a bit counter-intuitive.
I think I'll redesign my routes a bit, because it seems I'm trying to go down a route (pun!) that I shouldn't be going down.

Instead, I'll remove the PathParam and allow a POST on the parent URL, with the parameter as part of a regular Bean that gets passed in.

Nick Telford

unread,
Nov 19, 2013, 6:26:28 AM11/19/13
to dropwiz...@googlegroups.com
It's totally reasonable to expect to be able to annotate your resource method parameters with validation annotations, unfortunately, due to a limitation of Jersey 1.x, we can't do that yet.

Roy Jacobs

unread,
Nov 19, 2013, 6:34:45 AM11/19/13
to dropwiz...@googlegroups.com
On Tuesday, November 19, 2013 12:26:28 PM UTC+1, Nick Telford wrote:
It's totally reasonable to expect to be able to annotate your resource method parameters with validation annotations, unfortunately, due to a limitation of Jersey 1.x, we can't do that yet.

Ah! I read in this group that Jersey 2.x support will be forthcoming when some issues are fixed on their end, is there any update on that?

Nick Telford

unread,
Nov 19, 2013, 7:31:28 AM11/19/13
to dropwiz...@googlegroups.com
I believe progress on that front has stalled, and it looks fairly bleak. The problem is that method dispatch is now asynchronous, and would require a new interface to hook in to this process and carry custom context across the dispatch. It's not trivial, but so far the Jersey folks don't seem too fussed about addressing it :(

Roy Jacobs

unread,
Nov 19, 2013, 7:58:32 AM11/19/13
to dropwiz...@googlegroups.com
That's a shame. So basically not all functionality that was available for the traditional synchronous dispatching is not yet available for the new async model?
(apologies if this all seems obvious btw, I'm trying to move away from the C#/.NET world to the JVM, and thought Dropwizard would be a good way to start)


--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-user/wb6iwrpSrSE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dropwizard-us...@googlegroups.com.

Saad Mufti

unread,
Nov 19, 2013, 8:25:25 AM11/19/13
to dropwiz...@googlegroups.com
What about https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/monitoring/ApplicationEventListener.html and its associated https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/monitoring/RequestEventListener.html ? They might not handle all cases but things like metrics should be doable. Or are you saying because of the asynchronous nature of dispatch and these events, even the metrics wouldn't be measuring the properly bracketed method?

It would be nice to catalogue specifically the DW features that would be given up by going this route. Most of my resource classes use very little DW stuff in the methods other than metrics annotations and Optional<> returns for clean 404 support. Maybe the 404 could be handled by having a DW specific class DWOptional that threw an appropriate exception that could be mapped to a 404 response code. Just free associating here haven't really investigated throughly. But I'm afraid if DW gets stuck on Jersey 1.x it will start becoming a serious disincentive to adopt it going forward.

----
Saad

Roy Jacobs

unread,
Nov 19, 2013, 8:27:02 AM11/19/13
to dropwiz...@googlegroups.com
Btw, I'll stop derailing this question. I see there's another thread here that discusses the same things:

Saad Mufti

unread,
Nov 19, 2013, 8:30:09 AM11/19/13
to dropwiz...@googlegroups.com
I see you addressed some of this in another thread. Sorry if this is too much duplication, but it shos the community is interested :-)

----
Saad

Saad Mufti

unread,
Nov 19, 2013, 8:32:25 AM11/19/13
to dropwiz...@googlegroups.com
https://blogs.oracle.com/mira/entry/monitoring_of_restful_jersey_applicaiton

is a blog post from I believe the guy who wrote the Jersey event listener code. It seems to cover the metrics case.

----
Saad

On Tuesday, November 19, 2013 8:30:09 AM UTC-5, Saad Mufti wrote:
I see you addressed some of this in another thread. Sorry if this is too much duplication, but it shows the community is interested :-)

Saad Mufti

unread,
Nov 19, 2013, 8:39:35 AM11/19/13
to dropwiz...@googlegroups.com
But no access to the underlying java.lang.reflect.Method, so I don't see how annotations would be supported :-( Ok I've shot off my mouth enough, I'll let others speak.

----
Saad
Reply all
Reply to author
Forward
0 new messages