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 >> >

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 >> >

Yeah, I'm digging the idea of doing it when the user clicks "Run" in the WS Tester. Not sure about the 'content-type' / 'accept' headers bits unless you already provide those details in the URL (which I haven't seen if you do). I'll start work on a dialog though... _______________________________ Brian Fitzpatrick (aka "Fitz") Senior Software Engineer, SOA-P JBoss by Red Hat ----- Original Message ----- From: "Xavier Coulon" <xcoulon(a)redhat.com&gt; To: "Max Rydahl Andersen" <max.andersen(a)redhat.com&gt;, "Brian Fitzpatrick" <bfitzpat(a)redhat.com&gt; Cc: "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)lists.jboss.org&gt; Sent: Tuesday, April 24, 2012 1:46:03 AM Subject: Re: Processing JAX-RS operation URLs with parameters On Apr 24, 2012, at 8:31 AM, Max Rydahl Andersen wrote: > 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 ? Indeed, that's what Brian and I also noticed: behavior of IPath is not the same on MacOSX vs Windows. We ended up using simple String concatenation. > >>> **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 ? Actually, that would be very nice. Also, prompting for the 'content-type' / 'accept' headers would be nice, especially if the user wants to see a response in a specific format (application/json vs application/xml). /Xavier > >>> 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 >>> >> >