Java crumbs » Spring

WS testing

Lukáš Křečan — Tue, 08 Mar 2011 17:32:04 +0000

This post recaps some results of my experiments with WS testing. In last few months I have been working on several projects – Spring WS Test, Spring WS 2.0 testing support and finally on Smock. All of them reflect different approaches to WS testing. Today I am going recapitulate my findings focusing on testing producer/server side code. Consumer/client side will be covered in a following post.

Simple service, simple test

You may wonder what's the problem? Testing web services is easy. We just need to call the endpoint end verify the response. For a simple web service we can write a simple test like this

@Test
public void testPlus()
{
	assertEquals(3, endpoint.plus(1, 2));
}

The test is same as if I was testing a normal method.

Web Services tend to be complex

The trouble is that web services tend to be complex. Normal Java methods usually have few relatively simple parameters. On the other hand, web service request or response could be quite complicated which makes the service endpoint hard to test.

GetFlightsRequest request = new GetFlightsRequest();
request.setFrom("PRG");
request.setTo("DUB");
request.setServiceClass(ServiceClass.BUSINESS);
request.setDepartureDate(DatatypeFactory.newInstance().newXMLGregorianCalendarDate(2011, 02, 23, 0));
//more setter calls could be here

GetFlightsResponse response = endpoint.getFlights(request);

List flights = response.getFlight();
assertEquals(1, flights.size());
assertEquals(ServiceClass.BUSINESS, flights.get(0).getServiceClass());
//more assertions here

Such tests are bearable only until certain level of complexity. From certain level it's real pain. I really hate to call twenty setters to construct several levels of nested XML hierarchy and then to call dozens of getters to validate the response.

To define XML use ... the XML
The problem is that we want to create or validate an XML structure using wrong language. Java is just not suitable for the task. The best language to describe XML is, surprise, surprise, the XML. Would not it be easier to create XML files containing the request and response and just use them in the test?

GetFlightsRequest request = JAXB.unmarshal(getStream("request1.xml"), GetFlightsRequest.class);

GetFlightsResponse response = endpoint.getFlights(request);

DOMResult domResponse = new DOMResult();
JAXB.marshal(response, domResponse);

XMLUnit.setIgnoreWhitespace(true);
XMLAssert.assertXMLEqual(getDocument("response1.xml"), (Document)domResponse.getNode());

It's much better. This test will look exactly the same way regardless the complexity of the service. But it still have some shortcomings. The biggest one is that usually testing using only one request is not sufficient. I'd like to test the service using different inputs. In such case I have to create lot of XML files that differ just in few elements. It's a maintenance nightmare. If you change the service, you also have to change all the XML files.

Smock comes to help
Up until now we managed to test without any special framework except XMLUnit. Now we will start to use my precious Smock library. The test above can be rewritten to this form.

Map params = new HashMap();
params.put("from", "DUB");
params.put("to", "JFK");
params.put("serviceClass", "economy");
GetFlightsRequest request = createRequest(
					withMessage("request-context-groovy.xml")
					.withParameters(params), GetFlightsRequest.class);

GetFlightsResponse response = endpoint.getFlights(request);

validate(response, request)
	.andExpect(message("response-context-groovy.xml")
	.withParameter("serviceClass", "economy"));

The test is quite similar as the previous one. The difference is that it uses statically imported method createRequest to create a request and validate method to validate the response. The main advantage is that Smock methods support templates. So we can set just values we want to, the rest can be driven by the template. Moreover we do not need to deal with the request structure, parameters can be set into a simple flat map.


	${from}
	${to}
	2001-01-01
	${serviceClass}

Templates are even more useful when comparing the response


	
		OK1324
		2011-02-19T10:00:00
		
			${GetFlightsRequest.from}
			${IGNORE}
			${IGNORE}
		
		2011-02-19T12:00:00
		
			${GetFlightsRequest.to}
			${IGNORE}
			${IGNORE}
		
		${serviceClass}

We can ignore some elements, we can compare values based on the request elements and so on. Moreover, when we are using Smock library, we can leverage Spring WS 2.0 testing capabilities that Smock builds on. We can for example validate that the response is valid regarding to its schema.

validate(response).andExpect(validPayload(resource("xsd/messages.xsd")));

Cool, isn't it?

Testing the configuration
Sometimes unit test are not sufficient. Sometimes we want to test the configuration, interceptors, error handling and so on. No problem. If you are using Spring WS 2, you can use the built-in testing library. If you need templates or if you are using different framework like Axis 2, you can use Smock. The test looks similar.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("file:src/main/webapp/WEB-INF/spring-ws-servlet.xml")
public class GroovyEndpointTest {

	private MockWebServiceClient wsMockClient;

	@Autowired
	public void setApplicationContext(ApplicationContext context)
	{
		wsMockClient = createClient(context);
	}

	@Test
	public void testResponseTemplate() throws Exception {
		Map params = new HashMap();
		params.put("from", "DUB");
		params.put("to", "JFK");
		params.put("serviceClass", "economy");
		wsMockClient.sendRequest(
			withMessage("request-context-groovy.xml")
			  .withParameters(params))
			.andExpect(message("response-context-groovy.xml")
			  .withParameter("serviceClass", "economy"));
	}

The only difference is that we have to bootstrap the application context. Having done this, we can use the mock web service client to call our services. Even though this kind of tests is more complicated, we can use it to test object-XML mapping, endpoint resolution, error handling and configuration in general.

We have seen several different methods of WS testing. Each of them have advantages and disadvantages. If you keep you services simple, your tests are simple too. If the service is more complex, it makes sense to use XML for the test. Either using your own helper methods, Spring WS 2.0 test support or Smock.

All the samples could be downloaded from here.

Writing fluent API

Lukáš Křečan — Sat, 10 Jul 2010 13:12:19 +0000

In recent weeks I have been working with Arjen Poutsma on a brand new testing support for Spring Web Services. At least Arjen has been working, I have been just generating crazy ideas and he kept explaining me why we can't use them.

But it was quite interesting experience and I have learned a lot about fluent API design. Since it was my first fluent API and I am not an API expert, please take everything I mention here with grain of salt.

The task is simple. We need a way how to configure a mock. This mock has to validate that requests generated by our application are correct and after that the mock has to return some response. We want to write something like this:

Computer, when someone is trying to send a request, verify that the request contains value “a”, has header “header” and then respond with value “b”.

The requirements for the API are following:

It has to be simple for users. Mainly it has to be friendly to GUI addicts like me, that rely on code-completion all the time.
The library itself has to be simple
The API should be as fluent as possible
It has to be extensible

In the next part, I will try to describe several variants of the solution, each of them fulfilling the requirements differently. Please keep in mind that the code is simplified, it focuses solely on the API, not on the implementation. Moreover, the classes have been renamed to show what their main purpose is.

All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

Interface based version

code
The first variant is based mainly on interfaces. The test itself looks like this

	@Test
	public void testMock()
	{
		Mock mock = new Mock();
		mock.whenConnecting().expectValue("a").and().expectHeader("header").andRespondWithValue("b");

		//test code

		mock.verify();
	}

There is one entry point, class Mock

public class Mock {

	public RequestExpectations whenConnecting()
	{
		return new MockInternal();
	}

	public void verify()
	{
		//do something
	}
}

It just returns an internal class that implements RequestExpectations interface.

public interface RequestExpectations {

    ResponseActions expectValue(String value);

    ResponseActions expectHeader(String name);
}

All methods of this interface return ResponseActions interface

public interface ResponseActions {

	RequestExpectations and();

	void andRespondWithValue(String value);

	void andRespondWithError();

}

Please note that and() method allows chaining of request expectation.

This API is really IDE friendly. Code completion works like a charm. It's quite simple both from outside and inside. But this API has one big flaw. It's not extensible. Imagine that we would like to add an expectation that verifies a digital signature. We would have to add a method to the RequestExpectations interface. It is not possible neither for third parties nor for us, since this change would break backward compatibility.

Static factory

code
We can split the functionality and allow others to provide their own validators and response generators. We just have to change the interfaces

public interface RequestExpectations {

    ResponseActions expect(RequestMatcher matcher);
}

and

public interface ResponseActions {

	RequestExpectations and();

	void andRespond(ResponseCallback callback);
}

Now we have made the API extensible, but we have to provide an easy way how to create RequestMatchers and ResponseCallbacks. One way how to do it is a statically imported static factory.

public class StaticFactory {
	public static RequestMatcher value(String value)
	{
		return new RequestMatcher() {
			public void match(Object someParams) {
				//do something
			}
		};
	}
	public static ResponseCallback withValue(String value)
	{
		return new ResponseCallback() {
			public void doWithResponse(Object someParams) {
				//do something
			}
		};
	}
}

The test then can look like this.

import static net.javacrumbs.fluentapi2.StaticFactory.*;

public class MockTest {

	@Test
	public void testMock()
	{
		Mock mock = new Mock();
		mock.whenConnecting().expect(value("a")).and().expect(header("header")).andRespond(withValue("b"));

		//test code

		mock.verify();
	}
}

Such API is also fluent. It even resembles EasyMock API. The issue here is that code completion does not work as well as before. In Eclipse you have to type first letter of the method name before Ctrl+Space starts working. In Idea you have to press Ctrl+Shift+Space. But the advantage is that everyone can provide their own factory and extend the library seamlessly and consistently.

Super-static variant

code
We can go event further. We can get rid of RequestExpectations interface, remove Mock class and do statically most of the stuff. The test can look like this

import static net.javacrumbs.fluentapi3.StaticFactory.*;

public class MockTest {

	@Test
	public void testMock()
	{
		expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));

		//test code

		verify();
	}
}

It's simple and elegant. We even got rid of the strange and() method. The downside is that we usually have to use some ThreadLocals internally. But it looks almost like EasyMock. Cool.

Inheritance

code
Some people (like me) do not like static methods. It does not feel right, it's not object oriented programming. Can we do something similar, but dynamic? Yes, we can.

We just have to use inheritance. Just delete static keywords from the methods in StaticFactory class. We will also rename the class itself because it's not static any more.

We get

public class MockTest extends MockFactory{

	@Test
	public void testMock()
	{
		expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));

		//test code

		verify();
	}
}

The downside is, that we have to extend our class from MockFactory. Sometimes it's not possible. No problem, we can use a trick I have seen in Apache Camel DSL.

public class MockTest{
	@Test
	public void testMock()
	{
		MockFactory mockFactory = new MockFactory()
		{
			protected void configure() {
				expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));
			};
		};

		//test code

		mockFactory.verify();
	}
}

It's not as elegant as the direct inheritance, but it works. If we are brave enough, we can even use a closure.

public class MockTest extends MockFactory{
	@Test
	public void testMockClosure()
	{
		MockFactory mockFactory = new MockFactory()
		{{
				expect(value("a")).andExpect(header("header")).andRespond(withValue("b"));
		}};

		//test code

		mockFactory.verify();
	}
}

(I bet you did not know that Java has closures already).

So I have shown you four variants, which one is the best? I do not know, each of them has it's pros and cons. I personally like the last one the most. But the super static variant is not bad neither. Or the static? Or some mix between them? Some other? You have to make your own opinion.

References:
http://martinfowler.com/bliki/FluentInterface.html
http://martinfowler.com/dslwip/InternalOverview.html
http://camel.apache.org/routes.html
http://easymock.org/

Spring WS Security on both client and server

Lukáš Křečan — Mon, 07 Jun 2010 11:17:13 +0000

Recently, I have been playing with Spring WS with WS-Security. I just want to write down how it works. Do not except anything special, just simple example of basic security operations.

The example

We want to implement both client and server side. The client will sign the message, encrypt some part of it and add a timestamp. To make it more complex and real-life like we will sign the message using private key with alias “client” and encrypt the message using public key called “server”. Server will validate that the request is valid and will just sign the response using his key called “server”. Please note that I have picked Wss4j implementation because the configuration seemed to be easier than Xws.

Client

It's easy to do configure client interceptor like this (full configuration).

...

As you can see, there is nothing special. We just define which actions to take and properties. The only confusing part is, that key alias is defined as “securementUsername”.

Whit this configuration we will get following SOAP message.


	
		
			
				
				
					
						
							
								CN=Test Server,OU=Test
								1275904530
							
						
					
				
				
					fwFM7ShJ1xd7dTGrkh0410sTmW92OPB1q1fpzB21XFIe36siDDJWGgbw5B94yjmGK2YaPOWLb7cpVTYPzc9VUDs7Jc42CtrhT2H6eZ7CDiA60Ugz+qi2UyyfMDK6Vrdj9J68rij5P12AiBeTnd2wlhI29+71XbUpD5weHDHjMtQ=
					
				
				
					
				
			
			
				
					
					
					
						
							
						
						
						AU9utUgz5RylYCRDUAO0JWM48kM=
					
				
				
					NHjjgpb9/alUOq50CqPKLcdYrp7edYdKJDNvIhh+2OAhYdDvZmD1qGsVKd1H9oKPF17uaF2Sv3aY
					0le6BrvzVx3n2+nYYlHwAWlzBk7wsBt4vLll6q6juLCP+siupTIb1PeZDf3WrAbHUQh5oqjD6cZB
					Sc89pDspWRABQ8wPxYE=

				
					
						
							
								CN=Lukas Krecan,OU=Test
								1275900789
							
						
					
				
			
			
				2010-06-07T11:03:35.749Z
				2010-06-07T11:08:35.749Z
			
		
	
	
		
			
				
					
					
						
							
						
					
					
						81TEtUhHXo6iZeAmYrtYlm2ObAqOBpjfzf2VOVUg4Hs=
						
					
				
			
			2

Server config

To configure server, you have to define Spring WS server interceptor like this (full example).

No surprise here neither. The response will look like this.


	
		
			
				
					
					
					
						
							
						
						
						hEdDfxM6Nfs62Jxe8EOsELCDtUk=
					
					
						
							
						
						
						TTSRri5KJqXeMJfjzXyVmUewPxc=
					
				
				
					V5by3bOoGQNajfs7i9xQ+cbAqIkI0NS9N9FQlLb/dAuQfguE7jKRP9iypOeRLHCPr7g3BNg+NCrX
					6YcgDQ0TfXNhdL00AmoEfDmWSNvIVNE49kZEn3Ji/RW4VtdEiV79VD7Vuay0YAYGo9DSQvzq3FP6
					YEhfzfMqvfbWMdEKcO8=

				
					
						
							
								CN=Test Server,OU=Test
								1275904530
							
						
					
				
			
			
		
	
	
		
			3

As we have seen it's possible to configure WS-Security without much hassle. To learn more, visit the official Spring WS reference. You can download full example here.

Spring WS Test

Lukáš Křečan — Wed, 02 Sep 2009 19:15:51 +0000

Last few weeks I have been working on one of my pet projects. Its name is Spring WS Test. As the name implies, its main purpose is to simplify Spring WS tests.

Again, I am scratching my own itch. I am quite test infected and I have needed something that allows me to write functional tests of my application without having to depend on an external server. Until now, you basically had two options. This first one is to test WS client application using plain old JUnit together with a library like EasyMock. But usually this test are quite ugly and hard to read. Moreover this type of tests does not test your configuration. The second option is to create a functional test that calls an external mock service. But this solution requires you to have two JVM, its configuration is complicated and error prone.

I have been looking for something in between, for something that would allow me to write functional tests using JUnit and would be able to run in the same JVM as the test. Unfortunately I have not been able to find anything similar.

That's the reason why I have created Spring WS Test project. It's quite simple and easy even though I had to spent lot of my evenings getting it into a publishable state.

Basic configuration looks like this


  
  

  
  

  
  
     
         
            
            
         
     
     
         
             
                 concat(local-name(//soapenv:Body/*[1]),'/default-response.xml')

Here we have MockWebServiceMessageSender that replaces standard Spring WebServiceMessageSender. The replacement is done by MockMessageSenderInjector. The only other thing you have to do is to define ResponseGenerator. It's main purpose is to look for files in you test classpath and return them as mock responses.

Of course it has to decide, which file to use. By default a XPath expression is used to determine the resource name. In our example it is concat(local-name(//soapenv:Body/*[1]),'/default-response.xml'). It takes name of the payload (first soap:Body child) and uses it as a directory name. File “default-response.xml” from this directory is used as the mock response. Simple isn't it?

Of course you can define more complicated XPaths, you can use XSLT templates to generate your responses, you can validate your requests etc. More details can be found in the documentation.

Now I am looking for some end-user feedback. So please, if you are using Spring WS on the client side do not hesitate and test it. It should be stable enough to be used although there might be a bug here and there.

Spring WS fault detail

Lukáš Křečan — Sat, 23 May 2009 13:59:07 +0000

Spring WS project provides nice and versatile exception handling tools. But in some scenarios predefined Exception Resolvers are not sufficient. For example if you want to provide additional error info in the soap:fault detail like in this example:


   
   
      
         SOAP-ENV:Client
         Something wrong happened
         
            Error
            BigTrouble

Fortunately it is quite easy to add similar behavior using Spring WS. You can easily extend existing SoapFaultMappingExceptionResolver and customize the fault (please note that EndpointExeption is project specific exception that provides necessary data):

 public class EndpointExceptionResolver extends SoapFaultMappingExceptionResolver {
	private static final QName CODE = new QName("code");
	private static final QName SUB_CODE = new QName("sub-code");

	@Override
	protected void customizeFault(Object endpoint, Exception ex, SoapFault fault) {
		logger.warn("Exception processed ",ex);
		if (ex instanceof EndpointException) {
			EndpointException ee = (EndpointException) ex;
			SoapFaultDetail detail = fault.addFaultDetail();
			detail.addFaultDetailElement(CODE).addText(ee.getCode());
			detail.addFaultDetailElement(SUB_CODE).addText(ee.getSubCode());
		}
	}
}

Streaming a stream

Lukáš Křečan — Fri, 27 Feb 2009 10:53:01 +0000

I have another dirty trick for you. Let's imagine that you have a document server with following sophisticated interface.

public interface DocumentServer {
	/**
	 * Stores a document.
	 * @return document id
	 */
	public String storeDocument(InputStream in);

	/**
	 * Loads document with given id.
	 * @param id
	 * @return
	 */
	public InputStream loadDocument(String id);
}

It works well, until you realize, that you want to call the DocumentServer remotely, for example using Spring HttpInvoker.

HttpInvoker is a nice small tool, that lets you make remote method invocations over HTTP without much pain. It creates dynamic proxy, serializes all attributes using Java serialization, calls remote proxy, which deserializes arguments, calls the implementation and sends the result back in the same way. It is nice, simple and it works without any problem. You can configure it in five minutes. The downside is, that you have to have Spring Java application on both ends of the wire and all arguments that you send over the wire have to be Serializable.

And that's exactly the trouble we have with our DocumentServer. There is no standard InputStream implementation that implements serializable. Lets think about it. We need to have a stream that is able to stream itself into an ObjectOutputStream. Sounds strange, but it is quite easy. We can simply write a wrapper, that implements writeObject(ObjectOutputStream) method and that takes all the bytes from the underlying stream and writes them to the ObjectOutputStream. It is simple and it does not consume much memory.

Deserialization is much harder. We have to implement readObject(ObjectInputStream in) method, load the data and store them somewhere for later use. We can store them in the memory or in a temporary file. If the streams are larger, temporary file is better choice but we have to delete them after use and the implementation gets messy.

The good news is, that we do not have to implement it, it's already done by RMIIO library. They provide SerializableInputStream class that does exactly what we need. You just have to ignore Javadoc comment saying:

An additional layer around a RemoteInputStream which makes it Serializable and an InputStream. In general, this extra layer is not necessary and I do not recommend using this class. However, in the odd case where the callee really wants to get something which is already an InputStream, this class can be useful.

The only thing we have to do is to wrap all the streams into SerializableInputStream like this

new SerializableInputStream(new DirectRemoteInputStream(inputStream));

It can be done by hand written proxy, by dynamically generated proxy or by AOP.

Of course there are other alternatives. The easiest one is to create something like ByteArayInputStream that implements Serializable. If the streams are small enough, it's the best solution.

We can also try to use Hessian, but I had some troubles when method signatures were more complicated. And of course there is still a possibility to implement own remoting mechanism. After all, HTTP is meant to transport streams. But it would require lot of boilerplate code and I do not like boilerplate code.

Spring managed Hibernate interceptor in JPA

Lukáš Křečan — Sat, 24 Jan 2009 16:29:27 +0000

I have been trying to teach Hibernate injecting dependencies into Entities (I know, there is magic @Configurable annotation, I wanted to try it without magic). It is quite easy to do it using Hibernate interceptor (for example like this). But there is one drawback. It is not straightforward to inject interceptor into Hibernate when JPA abstraction is in the way.

It is simple to define interceptor in persistence.xml using hibernate.ejb.interceptor property. But it is only possible to specify class name, you can not inject Spring bean. If you read documentation to Spring LocalContainerEntityManagerFactoryBean there is no possibility to specify the interceptor bean there neither. But there is a way how to achieve it. First of all, you have to redefine Hibernate PersistenceProvider.

public class ConfigurableHibernatePersistence extends HibernatePersistence {
	private Interceptor interceptor;
	public Interceptor getInterceptor() {
		return interceptor;
	}

	public void setInterceptor(Interceptor interceptor) {
		this.interceptor = interceptor;
	}

	@SuppressWarnings("unchecked")
	@Override
	public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) {
		Ejb3Configuration cfg = new Ejb3Configuration();
		Ejb3Configuration configured = cfg.configure( info, map );
		postprocessConfiguration(info, map, configured);
		return configured != null ? configured.buildEntityManagerFactory() : null;
	}

	@SuppressWarnings("unchecked")
	protected void postprocessConfiguration(PersistenceUnitInfo info, Map map, Ejb3Configuration configured) {
		if (this.interceptor != null)
		{
			if (configured.getInterceptor()==null || EmptyInterceptor.class.equals(configured.getInterceptor().getClass()))
			{
				configured.setInterceptor(this.interceptor);
			}
			else
			{
				throw new IllegalStateException("Hibernate interceptor already set in persistence.xml ("+configured.getInterceptor()+")");
			}
		}
	}
}

(source)

Here we override method createContainerEntityManagerFactory in order to add postprocessConfiguration method call. In this method, it is possible to change Hibernate configuration as needed. Now the only thing to be done is configuring Spring to use our new PersistenceProvider. It is quite simple.

And that all folks, we have Spring configured interceptor even when using JPA abstraction. It would be better if similar classes were in Spring or Hibernate, but it's just few lines of code so feel free to copy them if you need to. If you know easier way how to do it, please mention it in the comments below.

Skrytý drahokam Springu

Lukáš Křečan — Thu, 22 Jan 2009 19:25:16 +0000

Dnes jsem koukal na rozhovor s Rodem Johnsonem, v kterém mluvil o novinkách ve Springu 3.0. Mezi řečí se zmínil o anotaci @Configurable, která je už ve Springu 2.5 a označil ji za skrytý drahokam. Protože jsem o něčem takovém slyšel poprvé, tak jsem se podíval do dokumentace a docela mě to zaujalo. (Teda, teď koukám, že jsem se o něčem podobném zmiňoval už před půl rokem zde, ach ta paměť). V zásadě jde o to, že obvykle funguje dependency injection jen u bean, které spravuje Spring. Takže například nejde použít u JPA entit a podobně. Což je docela škoda, protože pak musíme dělat umělou servisní vrstvu a objektový model tím docela trpí. Máme na jednu stranu třídy, které drží stav (entity) a na druhou stranu servisní třídy, v kterých je jen kód a stavu mají pomálu. Ale ve správném objektovém programování bychom měli mít třídy, které kombinují oboje. Takže například objekt User by měl mít metodu remove(), která by ho smazala z databáze. Jenže to by znamenalo, že by každá instance této třídy musela mít v sobě odkaz na EntityManager nebo ještě lépe DAO, což neumíme injektnout.

Možná si říkáte, že jsem se zbláznil, že to je ošklivé. Musím se přiznat, že mi je tento přístup taky cizí, ale asi je to jen otázka zvyku. Nejspíš jsem jen zvyklý na to procedurální programování, kde mám servisní procedury v singletonu a jim předhazuji hloupé datové objekty, které se o sebe neumějí postarat samy.

Anotace @Configurable je tu právě od toho, aby nám usnadnila injektování i do bean, které nejsou spravovány Springem. Předvedu na příkladu. Mám třídu Bean, které se dá podstrčit nějaký text.

@Configurable
public class Bean {
	private String text;
	public String getText() {
		return text;
	}
	public void setText(String text) {
		this.text = text;
	}
}

Mým cílem je zprovoznit tento test.

	public void testIt()
	{
		Bean bean = new Bean();
		assertEquals("Hallo",bean.getText());
	}

Všimněte si, že vytvářím novou instanci a koukám se, co je v ní nastaveno za text. Podle všeho by tam mělo být null. Ale pokud správně poladím Spring, tak tam může být cokoliv.

Prvním krokem je samozřejmě anotace @Configurable, která označí beanu jako kandidáta na injektování. V druhém kroku musím nastavit, co chci injektnout. Mohu například zvolit klasickou XML konfiguraci.

	
		
	

	

	
	Zde si všimněme několika věcí. Například toho, že Spring pozná to kam má co injektnout automaticky, podle jména třídy. Nicméně dají se použít i vlastní jména. Pak si všimněme použití rozsahu „protoype“. To dává smysl, já mohu new zavolat kolikrát chci (i když tam to protoype nedáte, tak se to chová stejně, takhle je to jen hezčí).  No a pak už nám zbývá jen magie. Pomocí prvního kouzelného slůvka  zařídíme, aby se použil AspectJ aspekt, který to všechno zařídí. Ano, musí se použít AspectJ, zázraky ani Spring nedovede. Zatím.  
	Druhé kouzelné slůvko  nastaví AspectJ, tak aby si podle potřeby při startu aplikace upravil třídy. Aby to totiž všechno fungovalo, tak je potřeba upravit bytecode. A to buď při kompilaci nebo při startu aplikace. Já jsem zvolil druhou variantu, která bohužel také vyžaduje, abyste to celé spouštěli s atributem virtuálního stroje -javaagent:spring-agent-2.5.6.jar. Pokud si kód budete zkoušet sami, tak na to prosím nezapomeňte.
	A to je vše, testy projdou bez problému. Vidíme, že Spring umí injektovat i do tříd, nad kterými na první pohled nemá kontrolu. A to aniž bychom nějak zvlášť museli študovat AspectJ. Všechno už máme pěkně připraveno. Samozřejmě, uvedený příklad je umělý, ale pokud bychom našli dost odvahy, tak můžeme bez problémů injektnout EntityManager přímo do entit. A to může být docela užitečné.
	Zdrojový kód je ke stažení zde, obzvláště doporučuji extra zvrhlou třídu MagicBean. No a pokud chcete umět Spring tak skvěle jako já, tak se mi ozvěte, můžu vás to naučit  .

Webové služby à la Spring

Lukáš Křečan — Tue, 25 Nov 2008 19:57:15 +0000

V poslední době docela často používal knihovnu Spring WS. Chtěl bych se s vámi podělit o zkušenosti, které jsem s tímto modulem udělal. Nejdřív bych měl ale upozornit, že nejsem expert na webové služby. O tom co je to port nebo binding mám jen mlhavou představu. Na druhou stranu jsem to nikdy vědět nepotřeboval. Nečekejte také žádný návod jak to používat. Původně jsem ho sice chtěl napsat, ale pak mi došlo, že bych jen kopíroval existující dokumentaci.
Než se ale pustíme do Spring-WS, začnu trochu zeširoka. Na webové služby se můžeme dívat ze dvou úhlů. Můžeme je vnímat jako trochu lepší vzdálené volání metod (RPC). Prostě označím metodu vhodně zvolenou anotací a nějaký framework se mi postará o to, aby tato metoda byla vzdáleně volatelná. Nijak zvlášť mě nezajímá to, jak bude komunikace probíhat. Prostě beru webové služby jako takovou trochu modernější Corbu nebo RMI.
Druhý přístup se na webové služby dívá z druhé strany. Bere je jako trochu vylepšený způsob výměny XML dokumentů. Při tomto přístupu je pro mě důležitý formát výměny dat, od něj se pak odvíjí způsob volání.
Samozřejmě oba přístupy nakonec skončí obdobně, liší se jen tím, co je pro mě důležitější. Spousta lidí se shoduje v tom, že druhý přístup dává větší smysl. Obvykle se dočtete, že při návrhu webové služby by se mělo začít u definice XML dokumentů, které budou sloužit pro výměnu dat (contract first). Dává to smysl. Definice dat je to, kde se budeme střetávat s konzumenty naší webové služby, XSD je to, co vidí a proti čemu programují. Nikoho nezajímá, jakou signaturu má naše metoda, konzumenty zajímá co všechno nám musí poslat a co my jim na oplátku pošleme jako odpověď.
Spring WS je postaven právě kolem contract-first přístupu. A musím přiznat, že je postaven docela dobře. Nečekejte super kvalitu, na kterou jste zvyklí od Springu. Spring WS je psán jinou partou lidí a občas člověk narazí na místa, která by šla udělat lépe. Nicméně i tak je to kvalitní knihovna a pokud jste zvyklí na Spring, konfigurace Spring WS vám přijde přímočará.
Než se vrhnu do popisu toho, jako co všechno Spring WS umí, zamysleme se nad tím, co si od takové knihovny představujeme. Já od ní chci několik věcí. Chci, abych se nemusel starat o mydlinky kolem SOAPu, chci se zabývat pouze zpracováním nákladu (payloadu), který mi v těch mýdlových bublinách přišel. Takže od WS knihovny chci, aby mi zpracovala SOAP, vybalila náklad a předala mi ho k zpracování. Protože nerad pracuji s XML, chci, aby mi pomohla s převodem z XML do objektů. U odpovědi chci aby udělala to samé, ale pozpátku. Pak by se také hodilo, aby mi pomohla s vygenerováním WSDL a pokud je to nutné s WS-Security. Když se na tyto požadavky podívám, zjistím, že už to všechno je vyřešeno. Zpracování SOAPu umí SAAJ, na serializaci XML máme taky hromadu frameworků. Stačí to všechno jenom pospojovat. A přesně to dělá Spring WS.
Co se mi na něm líbí je jednoduchá konfigurovatelnost. Nestalo se mi, že bych narazil na něco, co bych neuměl nakonfigurovat. Všechno je možné nastavit, snadno přeprogramovat a podobně.
Samozřejmostí je volba způsobu serializace z a do XML. Máte na výběr JAXB2, Castor, XStream, moje oblíbené XMLBeans a několik dalších. Vytvoření vlastního způsobu serializace je jen otázkou implementace dvou rozhraní.
Pokud potřebujete něco pokročilejšího, můžete použít interceptory. Ty fungují obdobně jako filtry u HTTP requestu, jsou ale spouštěny na úrovni SOAP dotazu a odpovědi. Spring WS obsahuje interceptor pro logování dotazů a odpovědí, který je docela užitečný. Navíc obsahuje interceptor, který umí spustit XSLT transformaci nad příchozím dotazem. To je super, pokud potřebujete upravovat formát dat. Například přidáte element do odpovědi. Ale v mezidobí, než všichni vaši klienti přejdou na novou verzi, musíte některým z nich vracet odpověď bez tohoto elementu. Není nic snazšího než napsat příslušnou XSLT šablonu, která ho z odpovědi vyhodí. To vám ušetří starosti s údržbou několika verzí té samé služby.
Interceptory navíc nabízejí skvělé místo pro úpravy jak dotazu tak odpovědi. Narazil jsem na následující problém, SAAJ negeneroval XML deklaraci na začátku XML dokumentu. Takové to . Bohužel jeden klient se toho dožadoval. Po půlhodině strávené výzkumem toho kde je chyba, jsem přišel na to, že z neznámého důvodu SAAJ implicitně XML deklaraci negeneruje. Všechno vyřešil trojřádkový interceptor, který nastavil správnou property tak, aby ji používal.
Co mě také potěšilo je generování WSDL. Člověk by si řekl, že je to samozřejmost. Nicméně například XFire měl s generováním WSDL z existujících XSD souborů pěkné problémy. Zamotal se v několikanásobných importech stejného XSD souboru a vracel mi nevalidní WSDL. To byl jeden z důvodů proč jsme přešli na Spring WS. (Druhý důvod byl, že už jeho vývoj skončil, teď se jmenuje CXF a konfigurace rozhodně není kompatibilní). Spring WS se stejným schématem neměl nejmenší problém, naopak potěšil takovou maličkostí jako je automatická změna URL webové služby ve WSDL podle toho, kde je nasazen.
Takže abych to shrnul, pokud děláte webové služby stylem contract-first a jste zvyklí na Spring, pak je Spring WS rozhodně dobrá volba. Jeho nevýhodou je, že vám nedá nic zadarmo. Chcete generovat WSDL? Musíte si to nakonfigurovat. Chcete validovat dotazy pomocí XSD? Musíte nastavit správný interceptor. Trochu nešikovné je, že pro integraci s frameworkem musíte implementovat jeho rozhraní nebo rozšířit jeho třídu. Nicméně pokud nemáte stovky různých webových služeb, tak vás pár obalovacích piditříd nezabije. Pokud je i malá obalovací třída pro vás moc, pak můžete použít anotace. Ty jsem ale nezkoušel, takže nemohu sloužit.
Mezi nevýhody Spring WS patří, že nepodporuje anotaci @WebMethod. Autoři tvrdí, že je to záměrně, že prý lidi nabádá ke škodlivému pohledu na webové služby jako na vzdálené volání metod. Nevím, jejich anotace @Endpoint mi nepřipadá o moc lepší. Ale i přes tyto nevýhody mi Spring WS připadá jako dobrá volba. Dává vám svobodu volby a to je podle mě docela užitečná věc.

Specific environment setting with Spring

Lukáš Křečan — Fri, 14 Nov 2008 19:11:40 +0000

There is one issue that people usually have with J2EE deployment. I call it specific environment setting. Imagine that you have several environments that you want to deploy your J2EE application to. For example development, test, stress test, staging or production. For all those environments you need specific settings like JDBC URL, JDBC user name and password, path to a directory for data export etc. The question is where to put such setting. If you store it in the WAR (JAR, EAR, SAR or other AR) you have to create specific archive for every environment.
It is not a big problem, provided you have an automated build. Nevertheless I do not like this solution. I like to have the same archive for all environments. This way I am sure that the application on production is exactly the same as the one I have tested on the test environment. Moreover, there is a problem with passwords. You have to make them part of the build process and effectively publish them by doing so.
One possible solution is to use JNDI. It is probably the best solution if you can use it. But what if you don't use big and heavy J2EE server. What if you use a servlet container like Tomcat or Jetty instead. In this case I have one of my favorite tricks for you. I use Spring configuration similar to the following one:

 
	
		
			
			  classpath:main-config.properties
			
			
			  file:///${user.home}/spring-test.properties

Spring tries to load a configuration file from user home directory. If the file is found, properties from the main-config file are overwritten by those found in the spring-test file. And you can even overwrite those by defining a system property with the same name.
I like it. This way every developer can have his own configuration. There is no danger of accidentally committing passwords to a source control system. You can use exactly the same WAR on every environment. It is relatively safe, although some system administrators do not like it. This way you can distribute an application over the internet without forcing users to unpack it, edit a config file and pack it again afterwards.