Re: [jbosstools-dev] Processing JAX-RS operation URLs with parameters
by Max Rydahl Andersen
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
>>
>
12 years, 8 months
Changes to JBoss Tools' parent pom affecting all JBT/JBDS Core & SOA Tooling builds -- please read!
by Nick Boldt
Recently, we moved the parent pom from version 0.0.4-SNAPSHOT to
3.3.0.Beta3-SNAPSHOT in trunk.
When we branch next week for the Beta3 code freeze, this version will
become the parent pom in the branch, and trunk will move to version
3.3.0.CR1-SNAPSHOT (then later to 3.3.0.GA-SNAPHOT, etc.)
Anyone who depends on the parent pom 0.0.4 can continue to do so (as
it's now in Nexus) but should sooner or later move up to use the correct
3.3.0.x version of the parent pom before the 0.0.4 snapshot disappears
from Nexus.
Details on this change: https://issues.jboss.org/browse/JBIDE-11157
If I've forgotten to cc: a SOA Tools project lead, please fwd this on.
If there's a soa-tooling mailing list you'd like me to cc: in future for
these sorts of changes, let me know.
Cheers,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 8 months
OpenShift Tooling : migrating the client plugins to the new REST API
by Xavier Coulon
Hi,
I just committed a bunch of changes in relation with JBIDE-11400 (Migrate current openshift plugins to the new RESTful client library) since work on JBIDE-11339 (Create an openshift client library for the new OpenShift REST service) that André and I have been working on for the last few weeks in now taking a good shape.
Everything has not been tested yet, and we'll keep testing and fixing issues in the next days, so don't hesitate to ping us if you have issues.
If you're interested in the java client library, it is living here for now: https://github.com/adietish/openshift-java-client/tree/rest, and it'll be merged into the openshift repo on github later this month, once work is done and Eclipse tooling is stabilized.
Best regards,
/Xavier
12 years, 8 months