To test a REST-based web service, I created a JUnit test that employs the Jersey client classes. Once I changed the resource location to the https URL, I received the error "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target". At first, following the ideas on this Stack Overflow thread, I added some code to set up a ClientConfig with a SSLContext for the Jersey Client. Then I created a new trust store with the server certificate (rather than importing into the default Java trust store) and pointed command-line arguments to this new trust store (and providing its password).
However I continued to get the same error. But when I imported the server certificate into the default Java trust store, the error went away. And when I commented out all the ClientConfig code, and just used this.restWSClient = Client.create(); things continued to work! It's possible I may not have referenced the new trust store properly but at this moment, it doesn't matter.
One thing to note, SoapUI, which I previously used to test another web service over https on the same server, did not seem to require any client-side configuration (i.e. set up server certificate in trust store). Not sure if it simply trusts whatever certificate that it sees.
Labels
.net
(1)
*nix
(1)
administration
(1)
Android
(2)
Axis2
(2)
best practice
(5)
big-data
(1)
business-analysis
(1)
code re-use
(1)
continuous-integration
(1)
Cordova-PhoneGap
(1)
database
(2)
defect
(1)
design
(3)
Eclipse
(7)
education
(1)
groovy
(2)
https
(2)
Hudson
(4)
Java
(1)
JAX-RS
(2)
Jersey
(3)
Jetty
(1)
localization
(1)
m2eclipse
(2)
MapForce
(1)
Maven
(12)
MySQL
(1)
Nexus
(4)
notes
(4)
OO
(1)
Oracle
(4)
performance
(1)
Perl
(1)
PL/SQL
(1)
podcast
(1)
PostgreSQL
(1)
requirement
(1)
scripting
(1)
serialization
(1)
shell
(1)
SoapUI
(1)
SQL
(1)
SSH
(2)
stored procedure
(1)
STS
(2)
Subclipse
(1)
Subversion
(3)
TOAD
(3)
Tomcat
(4)
UML
(2)
unit-testing
(2)
WAMP
(1)
WAS
(3)
Windows
(3)
WP8
(2)
WTP
(2)
XML
(4)
XSLT
(1)
Showing posts with label Jersey. Show all posts
Showing posts with label Jersey. Show all posts
Thursday, December 23, 2010
Thursday, August 12, 2010
Jersey, JAX-RS notes on Jersey 1.3 User Guide
- Jersey 1.3 User Guide
- a more detailed document than the "RESTful Web Services Developer's Guide", especially regarding JSON support and the Jersey client API
- example of "Builder" pattern utilized by Jersey client API, rather than the JavaBean get/set pattern:
8 JAXBBean bean = r. 9 type(MediaType.APPLICATION_FORM_URLENCODED_TYPE) 10 .accept(MediaType.APPLICATION_JSON_TYPE) 11 .post(JAXBBean.class, f);
Jersey, JAX-RS notes for RESTful Web Services Developer's Guide
- RESTful Web Services Developer's Guide
- can embed variables in the URIs. URI path templates are URIs with variables embedded within the URI syntax
- "A fundamental part of REST is that the next set of valid operations is encoded in the response from the last. This means that as long as you only use actions from the last operation you will always perform a valid operation according to the application protocol." - does this feature exist in Jersey?
- "If a character in the value of a variable would conflict with the reserved characters of a URI, the conflicting character should be substituted with percent encoding." - use case?
- If the application needs to supply additional metadata, such as HTTP headers or a different status code, a method can return a Response that wraps the entity, and which can be built using Response.ResponseBuilder.
- By default, a resource class can respond to and produce all MIME media types of representations specified in the HTTP request and response headers
Subscribe to:
Posts (Atom)