<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Brian,<div><br></div><div>Yes, the IJaxrsEndpoint interface provides the consumed ("content-type" header) and produced ("accept" header) mediatypes, so they can be used from the WSTestClientDelegate.</div><div><br></div><div>Best regards<br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">/Xavier<br><br><br></span>
</div>
<br><div><div>On Apr 24, 2012, at 3:38 PM, Brian Fitzpatrick wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Yeah, I'm digging the idea of doing it when the user clicks "Run" in the WS Tester.<br><br>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). <br><br>I'll start work on a dialog though...<br><br>_______________________________<br>Brian Fitzpatrick (aka "Fitz")<br>Senior Software Engineer, SOA-P<br>JBoss by Red Hat<br><br>----- Original Message -----<br>From: "Xavier Coulon" <<a href="mailto:xcoulon@redhat.com">xcoulon@redhat.com</a>><br>To: "Max Rydahl Andersen" <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>>, "Brian Fitzpatrick" <<a href="mailto:bfitzpat@redhat.com">bfitzpat@redhat.com</a>><br>Cc: "jbosstools-dev jbosstools-dev" <<a href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a>><br>Sent: Tuesday, April 24, 2012 1:46:03 AM<br>Subject: Re: Processing JAX-RS operation URLs with parameters<br><br><br>On Apr 24, 2012, at 8:31 AM, Max Rydahl Andersen wrote:<br><br><blockquote type="cite">Hey Brian,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">moved this to the right mailinglist.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">JBIDE-11337 is fixed in trunk. URL are now properly exported into the WS Tester. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Have fun ;-)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">cool.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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...<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">**Problem #1**<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> * jboss-as-kitchensink<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> - GET /rest/members<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> - GET /rest/members/{id:[0-9][0-9]*}<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The "Uri Path Template" associated with the second parameterized GET (that you see in the tree) is: "/rest/members/{id:[0-9][0-9]*}"<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">When it gets translated to an actual server-based URL (when you do Run As... and test it in the WS Tester), it becomes: "<a href="http://localhost:8080/jboss-as-kitchensink/[0-9][0-9]*">http://localhost:8080/jboss-as-kitchensink/[0-9][0-9]*</a>}"<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The actual URL should be: "<a href="http://localhost:8080/jboss-as-kitchensink/rest/members/{id:[0-9][0-9]*}">http://localhost:8080/jboss-as-kitchensink/rest/members/{id:[0-9][0-9]*}</a>"<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. <br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">yeah, sounds like that is fixed by xavier now.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Using IPath is not right here though - IPath obeys OS filesystem "laws" I believe ?<br></blockquote><br>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.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">**Problem #2**<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Here are the possibilities I've come up with for handling parameter input:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1) Leave it as is, showing the full URL with the parameter data as it comes out of the JAX-RS tooling.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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).<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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. <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm open to suggestions on how to handle this. <br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Next time I press Ok, the dialog is still shown but now remembering the values so a simply press on Ok works.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That allows rapid execution while still allowing user to actually enter values he might want changed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">WDYT ?<br></blockquote><br>Actually, that would be very nice.<br>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).<br><br>/Xavier<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Max, do you have any clue what that JIRA was for the URL-parameter-processing request? <br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">not yet, i'll find it eventually :)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">/max<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--Fitz<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Brian Fitzpatrick (aka "Fitz")<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Senior Software Engineer, SOA-P<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">JBoss by Red Hat<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></div></body></html>