Re: [jbosstools-dev] Processing JAX-RS operation URLs with parameters
Hey Brian,
moved this to the right mailinglist.
JBIDE-11337 is fixed in trunk. URL are now properly exported into the
WS Tester.
Have fun ;-)
cool.
> I've been looking at the issue about the JAX-RS operation
URLs with parameters (for the JIRA I can't seem to locate but I know exists) in the WS
Tester. It may be JBIDE-11337, but I think that actually is related and not exactly the
same. What I've run into are a few intriguing issues...
>
> **Problem #1**
>
> So let's say that we have a REST application, such as the Kitchen sink example.
It by default has two GET methods - one without any parameters and one that takes a single
id parameter. In the Project Explorer, you see the following tree:
>
> * jboss-as-kitchensink
> - GET /rest/members
> - GET /rest/members/{id:[0-9][0-9]*}
>
> The "Uri Path Template" associated with the second parameterized GET (that
you see in the tree) is: "/rest/members/{id:[0-9][0-9]*}"
>
> When it gets translated to an actual server-based URL (when you do Run As... and test
it in the WS Tester), it becomes:
"http://localhost:8080/jboss-as-kitchensink/[0-9][0-9]*}"
>
> Notice anything odd about the URL vs. the URI? In WSTesterClientDelegate, the
computeEndpointURI method translates the URI to an Eclipse IPath object, which seems to
truncate the leading part of the parameter text - "{id:" disappears, leaving an
odd (and invalid) URL without the extra bits. I think this is what's actually
happening with JBIDE-11337.
>
> The actual URL should be:
"http://localhost:8080/jboss-as-kitchensink/rest/members/{id:[0-9][0-9]*}"
>
> So something is happening in that computeEndpointURI method that's doing a
hatchet job on the URL. That's problem #1. If we can solve that, we can deal with the
other issue which is also entertaining.
yeah, sounds like that is fixed by xavier now.
Using IPath is not right here though - IPath obeys OS filesystem "laws" I
believe ?
> **Problem #2**
>
> With a valid URL that includes the "shape" of the URL parameters as RegEx,
we need the user to change it and provide his or her own value that is valid based on that
Regular Expression. I'm guessing the number of parameters could be anything from none
to 100, though I'm not sure why anyone would want to go that crazy. So that makes an
educated guess at probably 1-5 parameters to deal with on the URL.
>
> Here are the possibilities I've come up with for handling parameter input:
>
> 1) Leave it as is, showing the full URL with the parameter data as it comes out of
the JAX-RS tooling.
>
> 2) Pop up a dialog requesting & validating values for the named parameters
included in the URL, then replace the expressions with the user-provided values. On the
dialog have an option to turn off this feature and allow the user to turn it back on in
the Tester Preferences (which don't exist currently).
>
> Though I'm not a fan of automatically throwing dialogs in the user's face,
this would present the user with the options they need at the time they need them.
>
> I'm open to suggestions on how to handle this.
IMO, I would lave the URL as it is and then when you press Run detect this is an URL with
{} stuff in it which needs to be replaced.
Show the dialog in that case and ask for input and when user press ok, remember the values
for that URL, execute the generated url but keep the original URL in the dialog.
Next time I press Ok, the dialog is still shown but now remembering the values so a simply
press on Ok works.
That allows rapid execution while still allowing user to actually enter values he might
want changed.
At some point you could have a [ ] replace URL with generated URL checkbox that would
allow for skipping the dialog since it is no longer a {} based url.
WDYT ?
> Max, do you have any clue what that JIRA was for the
URL-parameter-processing request?
not yet, i'll find it eventually :)
/max
>
> --Fitz
>
> _______________________________
> Brian Fitzpatrick (aka "Fitz")
> Senior Software Engineer, SOA-P
> JBoss by Red Hat
>