Archive for the ‘J2EE’ Category
« Older EntriesTesting SSL (HTTPS) clients with Junit and Jetty
Wednesday, July 14th, 2010
Posted in: https, junit, ssl, unit test J2EE, java, maven 2, open source.
I recently ran into a situation where a web service client had issues when invoking a webservice via HTTPS. To reproduce, I needed a lightweight, JUnit-based test to reproduce the problem and write a regression test. Here is how I got it to work:
First, I used the basic HTTP test setup. Now however, I needed Jetty to provide a HTTPS connector. For this to work, Jetty – just like any other webserver, such as apache – needs a server certificate and a private key in a keystore. To create the keystore, I simply followed the excellent Jetty SSL guide. Namingly, I did this (using Ubuntu, see the above link for alternatives):
openssl genrsa -des3 -out jetty.key openssl req -new -x509 -key jetty.key -out jetty.crt openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12 $JAVA_HOME/bin/keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
Once I had the keystore set up, I placed it in the src/main/resources folder (the root of the classpath, in case you’re not a maven user) and extended the HttpTestServer like so:
import java.net.URL;
import org.junit.Ignore;
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.security.SslSocketConnector;
/**
* A test server for testing SSL requests.
*
* @author Olaf Otto
*/
@Ignore
public class SslTestServer extends HttpTestServer {
private static final int HTTPS_PORT = 50443;
public SslTestServer() {
}
public SslTestServer(String mockData) {
super(mockData);
}
@Override
protected void configureServer() {
super.configureServer();
Connector secureConnector = createSecureConnector();
getServer().addConnector(secureConnector);
}
private Connector createSecureConnector() {
SslSocketConnector connector = new SslSocketConnector();
connector.setPort(HTTPS_PORT);
URL keystoreUrl = getClass().getClassLoader().getResource("keystore");
connector.setKeystore(keystoreUrl.getFile());
connector.setKeyPassword("test");
return connector;
}
public static void main(String[] args) {
SslTestServer server = new SslTestServer();
try {
server.start();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
(I added the @Ignore annotation as I placed the class in the test sources folder, though it’s not a test…)
You might use it in your JUnit-based test like so:
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
/**
* @author Olaf Otto
*/
public class MySslTest {
private SslTestServer _server;
@Before
public void startServer() throws Exception {
_server = new SslTestServer();
_server.start();
}
@After
public void stopServer() throws Exception {
_server.stop();
}
@Test
public void mySsltest() {
_server.setMockResponseData("<xml>My client expects this response</xml>");
// Perform tests on port 50443...
}
}
Here is the whole package as a maven 2 project (including the keystore with a self-signed certificate). Download, unzip, and give it a try (mvn test).
Lightweight testing of (webservice) HTTP clients with JUnit and Jetty
Wednesday, July 14th, 2010
Posted in: http clients, junit, test, webservices J2EE, java, maven 2, open source.
If you’re working with webservice clients you will certainly have noticed the complexity of integration-testing your webservice clients. Building webservice clients can already be quite a complex task, but providing a mock-up webservice backend delivering useful test responses is quite often just to much work, if not impossible, since many web service backends are very complex constructs. Furthermore, setting up a backend for each integration test consumes valuable build time.
As an alternative, one may simply replace the backend with a mock HTTP server that does one thing: deliver the expected webserver response – i.e. XML data – when called by the client. All you need to set this up is a HTTP server and a pre-recorded service response (quite often this comes with WS client specifications). If you don’t have this data, you can record it, for example using a proxy server in between your WS client and a real WS backend, or a tool such as wireshark.
The recorded XML response thus represents your assumptions against which you test the client. This makes your tests fast, lightweight and a lot better to understand.
Here is my Jetty-based test HTTP server:
package de.sysbsb.test;
import static javax.servlet.http.HttpServletResponse.SC_OK;
import static org.apache.commons.io.IOUtils.write;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.io.IOUtils;
import org.junit.Ignore;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.HttpConnection;
import org.mortbay.jetty.Request;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;
/**
* A server for answering HTTP requests with test response data.
*
* @author Olaf Otto
*/
@Ignore
public class HttpTestServer {
public static final int HTTP_PORT = 50036;
private Server _server;
private String _responseBody;
private String _requestBody;
private String _mockResponseData;
public HttpTestServer() {
}
public HttpTestServer(String mockData) {
setMockResponseData(mockData);
}
public void start() throws Exception {
configureServer();
startServer();
}
private void startServer() throws Exception {
_server.start();
}
protected void configureServer() {
_server = new Server(HTTP_PORT);
_server.setHandler(getMockHandler());
}
/**
* Creates an {@link AbstractHandler handler} returning an arbitrary String as a response.
*
* @return never <code>null</code>.
*/
public Handler getMockHandler() {
Handler handler = new AbstractHandler() {
public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch) throws IOException, ServletException {
Request baseRequest = request instanceof Request ? (Request) request : HttpConnection.getCurrentConnection().getRequest();
setResponseBody(getMockResponseData());
setRequestBody(IOUtils.toString(baseRequest.getInputStream()));
response.setStatus(SC_OK);
response.setContentType("text/xml;charset=utf-8");
write(getResponseBody(), response.getOutputStream());
baseRequest.setHandled(true);
}
};
return handler;
}
public void stop() throws Exception {
_server.stop();
}
public void setResponseBody(String responseBody) {
_responseBody = responseBody;
}
public String getResponseBody() {
return _responseBody;
}
public void setRequestBody(String requestBody) {
_requestBody = requestBody;
}
public String getRequestBody() {
return _requestBody;
}
public static void main(String[] args) {
HttpTestServer server = new HttpTestServer();
try {
server.start();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public void setMockResponseData(String mockResponseData) {
_mockResponseData = mockResponseData;
}
public String getMockResponseData() {
return _mockResponseData;
}
protected Server getServer() {
return _server;
}
}
You can use it in a JUnit test like so:
package de.sysbsb.test;
import java.io.IOException;
import java.io.InputStream;
import org.apache.commons.io.IOUtils;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
/**
* @author Olaf Otto
*/
public class MyClientTest {
private HttpTestServer _server;
@Before
public void startTestServer() throws Exception {
_server = new HttpTestServer();
_server.start();
}
@After
public void stopTestServer() throws Exception {
_server.stop();
}
@Test
public void someClientTest() throws IOException {
_server.setMockResponseData("<xml><testdata>hello, world</testdata></xml>");
// or as a much more elegant alternative:
_server.setMockResponseData(getRecordedResponse("testdata.xml"));
// run your client tests, using the HttpTestServer.HTTP_PORT
}
private String getRecordedResponse(String recordedResponseFile) throws IOException {
InputStream testDataStream = getClass().getClassLoader().getResourceAsStream(recordedResponseFile);
return IOUtils.toString(testDataStream);
}
}
Here are is the HTTP test server and a JUnit test example as a maven 2 project.
5 CommentsUsing RPC-style, encoded Axis 1 webservices with spring-remoting
Monday, October 12th, 2009
Posted in: Axis 1, Jax-ws, Spring-Remoting J2EE, System architecture, java, open source.
Preamble
When working with enterprise integration you will quite often deal with the integration of legacy systems.
I was recently tasked with the integration of webservices and much to my surprise there are huge issues when attempting to integrate old webservices (i.e. pre axis-2 and pre jax-ws webservices).
These webservices use outdated or unsupported methods, such as rpc-style/encoded communication, or even worce, outdated elements in the XML messages, for instance <multiref>’s. Having to integrate such services of course implies that you cannot change anything on the server side, and thus the outdated format must still be consumed by your webservice client.
This however is a huge problem, since the current WS implementations, such as the popular axis2 framework, do simply not support these outdated formats.
What surprised me the most about this is that webservices are designed to make systems independent by defining a common communication and data format, which is the exact opposite of what is going on here – and these formats are not that old, actually, they where pretty common just about 5 years ago.
Developers facing these issues are taking rather desperate measures to work around these problems, such as using on-the-fly XSLT transformation to convert incoming and outgoing WS messages. However, this binds your application even stronger to the outdated format and specific service data.
In my case I wanted to use Spring-remoting. Since the service was RPC-style, I wanted to use the JaxRpcPortProxyFactoryBean to create an on-the-fly proxy implementing the service interface. What I did not want to do is having to write any additional code to consume the service. Furthermore, I wanted the complex objects transferred by the services to be represented by standard JAVA beans, and not be generated using the wsdl2java axis1 tools since they contain a lot of ugly dependencies. Here is how I got this to work.
Read the rest of “Using RPC-style, encoded Axis 1 webservices with spring-remoting”
Running mvn:release with Subversion 1.5.x
Monday, March 23rd, 2009
Posted in: J2EE, SCM, System engineering, java, maven 2, open source, subversion.
When attempting to prepare a release using maven and the maven-release-plugin, you are currently very likely to see your build fail with a message such as:
[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists
If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.
This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:
Read the rest of “Running mvn:release with Subversion 1.5.x”
Modular development with OSGI about to be very, very popular – finally.
Monday, March 2nd, 2009
Posted in: J2EE, JPA, OSGI, System architecture, eclipselink, java, open source, spring.
It’s quite exciting to see the tremendous progress in development tools, patterns, frameworks and libraries since the release of JAVA 1.0 in 1996.
Within just thirteen years, development improved from the first applets, from the dark ages of the first EJB standardization attempts and a lack of suitable development processes into an age where aspect oriented programming, dependency injection and a freely available range of lightweight yet extremely powerful frameworks, libraries and API’s finally permitted the humble programmer to do what he always wanted to do – analyze problems, and elegantly write them down without spending all of his precious time on the syntax.
I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.
Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.
Modules larger than classes with OSGI
Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.
Read the rest of “Modular development with OSGI about to be very, very popular – finally.”
Maven, Surefire, remote debugging and the -javaagent switch
Monday, February 2nd, 2009
Posted in: J2EE, java, maven 2, spring.
When using maven surefire in conjunction with remote debugging (mvnDebug, for instance)
it seems necessary to disable forking of the test executions into separate processes, as the remote debugging works process wise. This is usually done by setting the the fork mode to never, e.g. by specifying -DforkMode=never on the command line.
This is, however, a misunderstanding. mvnDebug is there to enable debugging of the maven process and not of the surefire execution – and disabling forking may have various side effects. One of those is the use of Java agents. When using agents, e.g. for loadtime-weaving in the Spring Framework, one often specifies a -javaagent: as a JVM argument for surefire:
Read the rest of “Maven, Surefire, remote debugging and the -javaagent switch”
Solving the eclipselink (former toplink) issue with HSQLDB
Tuesday, August 12th, 2008
Posted in: J2EE, JPA, eclipselink, java.
When using the great hypersonic java database (hsql) with eclipselink 1.0, i stumbled upon a schema generation (ddl generation) issue. It appears as though eclipselink generates “CREATE TABLE…” statements containing UNIQUE keywords which are incompatible with HSQLDB.
As it turned out, there already is an issue filed for the problem (240618).
The resulting exceptions look like this:
[EL Warning]: 2008.08.12 11:01:13.134--ServerSession(28607378)--Exception [EclipseLink-4002] (Eclipse Persistence Services - 1.0 (Build 1.0 - 20080707)): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Unexpected token: UNIQUE in statement [CREATE TABLE ... (ID INTEGER UNIQUE]
Error Code: -11
Read the rest of “Solving the eclipselink (former toplink) issue with HSQLDB”
Configuring Eclipse Ganymede with subversion in Ubuntu 8.04
Sunday, July 13th, 2008
Posted in: J2EE, SCM, System engineering, eclipse, java, subclipse, subversion, subversive, ubuntu.
After installing the all-new Eclipse ganymede (by downloading it from the eclipse site) under ubuntu 8.04 i ran into some trouble after installing version 1.4.1 of the subclipse subversion plugin.
Long story short, subclipse requires subversion 1.5, but ubuntu 8.04 provides 1.4.x.
If you still want to use subclipse with ganymede in ubuntu, there are only two ways two achieve this – both of which i cannot recommend because they are hacks or bad compromises.
Read the rest of “Configuring Eclipse Ganymede with subversion in Ubuntu 8.04″
Howto use acegi-security and the @Secured annotation for method interception
Friday, July 4th, 2008
Posted in: J2EE, System architecture, acegi, java, spring.
Acegi-security (now spring-security) provides a @Secured (org.acegisecurity.annotation.Secured) annotation.
Classes using this annotation can be processed by a suitable BeanPostProcessor, which will proxy the class so that calls to @Secured methods are intercepted and the required authentication is validated against the acegi security context. Note that the following is a configuration for acegi-security, things might be different with spring-security.
2008-07-12: Comment: It is indeed a lot simpler using spring-security, as Craig Walls demonstrates in this posting in his blog “Spring-Loaded”).
In order to activate the post processing for the @Secured annotations, a spring configuration such as the following is required:
Read the rest of “Howto use acegi-security and the @Secured annotation for method interception”
Why it’s better to integrate XML schema files into the classpath
Saturday, May 10th, 2008
Posted in: J2EE, System architecture, java, spring.
When using schema files in your XML configuration, it’s might happen that your XML parser will attempt to actually download the schema file using the configured schema URI.
This is the case when there is no mechanism for resolving the schema URI to a local schema file (as, for example the bean handler registration in spring) or when such a mechanism fails.
Read the rest of “Why it’s better to integrate XML schema files into the classpath”
