Archive for the ‘spring’ Category


After spending some time with Liferay and doing a bunch of portlets, I noticed that they share some common functionality which is just copy-pasted which is wrong.

I also knew that Liferay offers its Service system – a service is a combination of Interface and Util class that land into tomcat’s lib/ext folder backed up by implementation located in either portlet or an ext environment and some spring xml to wire them up.

A first approach suggested that this is going to be a piece of cake but unfortunately I got NPE 🙁

So I started looking through Liferay source code to find out how service-builder generated services fetch implementation from global spring context and expose it to the rest of portlets through Util class. It all seemed as easy as casting Object into given interface buf unfortunately wasn’t and I got ClassCastException (spring forums recognizes as not programming to interfaces…)

I was kind of stuck.

So maybe there was something special about classes generated by service-builder  which makes them accessible from non-owning-portlet.

Class loader proxy

The answer is yes and it’s called Class loader proxy – the architecture that grew from the need to allow inter-portlet communication across tomcat class loader. It transformed into somewhat complex architecture, that requires following steps:

  1. Create an interface
  2. Wrap your code in static calls using service-util
  3. Acesses your impl through spring bean context
  4. Wrap bean aquired from bean context in Class loader proxy.
  5. Store proxy inside local portlet context.
As you can see number of layers that need to be written for a single method call can cause a headache. Additionally  CLP uses MethodKey/MethodInvocation classes internally which makes it even more complicated.
Exposing a single method through all these layers seemed rather exaggerated task but this way I could focus on building all the layers by hand and finally see my implementation class called properly from different portlets.

APT generator for boilerplate

At this point I felt the need for some kind of code-generator that would free me from declaring all these service/clp layers by hand and I reminded myself that Java 5 offered a tool called APT. APT is annotation pre-processor used by JPA2 authors to create type-safe Criteria API (in java6 it’s part of javac compiler). Using it is as simple as placing annotaton on desired item, declare processor being used and your annotation is pre-processed during some phase before compilation and compiled – magic!

Generating Liferay-service code with APT

After this a big lengthy introduction I can finally say that in this post I’m going to concentrate on building LiferayService processor that will generate Liferay’s service boilerplate code, using java interface as starting point. I’m fully aware of the factthat Liferay’s service builder generates interface from implementation but for most people I spoke with, this is counter-intuitive so I’ll stick to contract-first approach.

Afterwards I’ll show you how to create sample ext-plugin project in order to test your new processor in action.

If you don’t have any experience in building annotation processor I recommend reading Jorge Hidalgo annotation series which starts from the very basics and finishes on writing simple annotation Processor.

Define annotation

As you can see the annoation is only preserved for compile-time, that’s all we need for annotation processor.

public @interface LiferayService {
	public String value() default "portalClassLoader";
	public String initMethod() default "afterPropertiesSet";

Define view – templates for generated code

Now following best-practices adviced by Jorge from the formentioned blog entry I decided to use velocity template engine as view. We’re going to need 2 templates LiferayClp/LiferayUtil.

Their task is not that complicated:

  • add package declaration
  • add class declaration – using original name + suffix (Clp/Util)
  • add declaration for all passed methods
  • add init-method declaration
  • add class loader fetch

Define model – pass pieces of information from processor to view

All the pieces of information required by view are contained in processor model:
	public final Name getClassName() {
		return get(KEY_CLASS_NAME);

	public final Name getPackageName() {
		return get(KEY_PACKAGE_NAME);

	public final String getClassLoader() {
		return get(KEY_CLASS_LOADER);

	public final String getInitMethod() {
		return get(KEY_INIT_METHOD);

	public final Map getMethods() {
		return get(KEY_METHODS);

	public final Map getModelMap() {
		return Collections.unmodifiableMap(modelMap);

	public String getQualifiedName() {
		return getPackageName() + "." + getClassName();

	public Set getSuffixes() {
		return EnumSet.allOf(Suffix.class);
The code above is just an excerpt to see the main interface, you can view whole model here.

Get list of methods that need to be proxied

So now we have to decide what methods are the right ones that we would like to use in our service. Using interface as an entry point makes it a little bit easier since we don’t need to distinguish between implementation methods and some utility methods – getMethods can just take all methods that are abstract and non-native:

	private Map getMethodsToProxy(TypeElement classElement) {
		Map methods = new HashMap();

		List members = processingEnv.getElementUtils().getAllMembers(classElement);

		UniqueNameSupplier uns = new UniqueNameSupplier();

		for (Element member : members) {
			if (isInterfaceMethod(member)) {
				String methodName = uns.supplyUniqueName(member.getSimpleName());
				methods.put(methodName, member);

		return methods;

It uses UniqueNameSupplier class which might need some extra attention – CLP class contains list of fields that share their name with proxied method name. So for each interface method we have a method declaration and field declaration but there is no mechanism that mimics method overloads for fields, so we just need to make sure that field names are unique. The uniqueness of CLP field is achieved by giving field name the same name as method and in case there’s a potential name-clash appending a number that prevents it – not a very sofisticated name-mangling.

Combine it all together

In order to use it inside IDE like Eclipse it’s best to have a simple archive – that’s why I decided to use maven assembly plugin with a simple configuration that just filters out all META-INF directories in order to preserve processor service file.


Basically this is it – there are some other extension points that you might use but feel free to explore them on your own:)

Sources and binaries

Sources are available on github.
Binaries in my private repo.

In my next installment I’ll write some basic usage scenario with ext-pluign and sample portlet.

That’s it!

Problem description

Another approach to the memoization topic mentioned previously came to me quite recently based on a problem with webservice call.

Imagine you have a webservice request/response exchange that’s taking a long time not only due to network latency but also due to the fact that your ws-logic performs a complicated ldap query.

So there are at least 3 reasons that might cause you a headache:

  1. slow internet connection
  2. slow ldap search
  3. big number of results that need to downloaded

In order to improve this situation results of method call might be cached inside ws-client’s code using ehacache. Cached entries will be identified based on method’s signature and passed arguments. The arguments should implement Serializable interface but this is already fulfilled since objects are passed through webservice calls.

Caching should be transparent to the caller – which should not know whether results he got were fetched from remote server or local cache. Additionally it should be configurable which methods calls should be cached or not and last but not least – since cached entries are identified by some key – it should be possible to define custom key-generator that would give the user freedom in defning key algorithm.

All the above requirements are summarized below:

  • webservice client api defined as interface
  • webservice client implementation that performs call to server
  • methods are chosen based on annotations
  • wraper defined as dynamic proxy so calls to client api are transparently may be cached and user is not aware if results come from cache or real call

Solution description

The solution will be spring-specific since Spring supports ehacache out-of-the-box.

Existing solutions

There exists already at least 3 solutions:

and somehow all of them combined fill the picture of what I’d expect from such a library:

  1. Easy configuration with possibly as little xml as possible – smth like <context:component-scan> element with reasonable defaults
  2. Defining one annotation that enables method caching
  3. Including/Excluding methods from caching using annotation
Solution description

The approach descried in this post is realised by providing 3 main elements:

  1. Custom namespace handler implementing NamespaceHandlerSupport
  2. Custom bean definition parser extending AbstractSingleBeanDefinitionParser
  3. Custom BeanPostProcessor implmenting BeanFactoryAware interface
  4. Custom xsd

All points above respond to the requrements:

Points 1 and 2 let you declare usage of method cache with just one line of xml (after defining memoize namesapace) and creates EhCacheManagerFactoryBean and EhCacheFactoryBean behind-the-scenes freeing you from writing these explicitly inside you xml application context.

   cache-name="pl.bedkowski.code.memoize.sample.METHOD_CACHE" />

Point 3 finds classes annotated with Memoize annotation inside current context and wraps them inside Memoizer proxy, as well as fetches EhCacheFactoryBean instance created in the previous step.

public class WebServiceClientImpl implements WebServiceClient {

The Memoize annotation contains 2 properties:

  • keyGenerator – key generator class (must implement KeyGeneratorinterface)
  • type – one of Type.INCLUDE_ALL/Type.EXCLUDE_ALL

I think the last one needs some further explanation – it lets you define strategy for handling methods.

  • Default is Type.INCLUDE_ALL – which means that all methods that have non-void return type will be cached unless explicitly marked with Exclude annotation.
  • The reverse is Type.EXCLUDE_ALL which means that no method call will be cached unless marked with Includeannotation.

Sources, packages

Source available on github
Binaries available in repo

UPDATE: See updated version using ejb 3.1 compilant with any application server here.

Ostatnio zdażyło mi się trafić na dosyć intrygujący problem: testy junitowe odpalane były poprzez runner’a spring’owego co umożliwiało wstrzykiwanie zależności poprzez config testowy. No ale to wszyscy znamy – problem pojawił w momencie gdy chciałem dodać runner’a mockito’wego gdyż adnotacja @RunWith nie oferuje takiej możliwości, no i już byłem przekonany, że trzeba będzie zakasać rękawy i napisać jakieś api np. z użyciem dekoratora, ale jak zwykle wyszedł ze mnie leń i postanowiłem sprawdzić czy ktoś już tego czasem nie zrobił.

Okazało się, że nie, ale ze względu na to, że @RunWith została dodana nieco późno i nie była do końca przemyślana. W junit’cie 4.7 wprowadzono tzw. Intereceptors ale zmieniono ich nazwę wraz z  wersją 4.8 na Rule.

Co daje nam ta adnotacja – możemy ją zaaplikować do publicznej własności naszego testu, i musi on implementować interfejs MethodRule. Reszta to już bułeczka z masełkiem – MethodRule zwraca Statement‚a, który w działaniu przypomina nieco advice’a Around, znanego użytkownikom AOP – zawijamy sobie statement, wywołujemy co nam trzeba, następnie execute na oryginale i już. Dla przykładu stwórzmy taka klase, która pozwoli nam tworzyć mocki, mockitowe z wykorzystaniem adnotacji @Mock.

package pl.bedkowski.code.rules;

import org.junit.rules.MethodRule;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.Statement;
import org.mockito.MockitoAnnotations;

public class InitMocks implements MethodRule {

	public Statement apply(final Statement stmt, FrameworkMethod arg1, final Object arg2) {
		return new Statement(){
			public void evaluate() throws Throwable {


No i jakis przykladowy tescik:

package pl.bedkowski.code.rules;

import static org.mockito.Mockito.when;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.mockito.Mock;

interface SomeInterface{
	String doSmth();

public class SampleTest {

	public MethodRule i = new InitMocks();

	private SomeInterface my;

	public void testing() throws Exception {

Jakiś czas temu szukając informacji o szybkiej konfiguracji springa oraz połączeniu go z JAXB natrafiłem na blog Michała Mecha (strona Michała nie jest już dostępna – tekst w wayback machine)który to opisywał wspomniany przeze mnie problem.

Udało mi się w miarę sprawnie przenieść przykład, który zaprezentował na „własne podwórko” i zamiast wstrzykiwać do beana scieżkę do pliku który miałbyć zamieniony poprzez JAXB na obiekt, mogłem wstrzykiwać gotowy obiekt, a bean jak zwykle po prostu nie był swiadom skąd się ten obiekt wziął – z xml’a, czy może ktoś bo sobie „poskładał” łącząc odpowiednio pojo z mappingu xml’owego. Pojawił się tylko mały zgrzyt w momencie, gdy okazało się, że takich podmionionych bean’ów mam 40…

Zacząłem szukać jakiegoś sposobu aby uprościć konfigurację i zamknąć wszystko w jednej linijce i faktycznie udało się wykorzystując poszczególne elementy:

  • dodając do konfiga xml’owego przestrzeń nazw oxm
  • wykorzystując property editora
  • dodając element nadrzędny dla docelowego bean’a

Zmodyfikuje nieco oryginalny przykład w celu prezentacji rozwiązania:

Najpierw property editor w celu zamiany String’a na Source xml’owe:

package pl.bedkowski.test;

import java.beans.PropertyEditorSupport;


public class String2StreamSource extends PropertyEditorSupport {

	public void setAsText(String filePath) {
		setValue(new StreamSource(new File(filePath)));


No i kontekst apliacji:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""


	<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
	  <property name="customEditors">
	      <entry key="javax.xml.transform.Source">
	        <bean class="pl.bedkowski.test.String2StreamSource"/>

	<oxm:jaxb2-marshaller id="jaxb2Marshaller">
		<oxm:class-to-be-bound name="pl.michalmech.config.Config"/>

	<bean id="configParent"  class="pl.michalmech.config.Config" factory-bean="jaxb2Marshaller" factory-method="unmarshal" abstract="true" />

	<bean id="config1" parent="configParent">
		<constructor-arg value="config1.xml" />

	<bean id="config2" parent="configParent">
		<constructor-arg value="config2.xml" />

	<bean id="config3" parent="configParent">
		<constructor-arg value="config3.xml" />

	<bean id="config4" parent="configParent">
		<constructor-arg value="config4.xml" />


Na początku może się wydawać, że to więcej jednak jeżeli odejmiemy te pare(-naście) linijek podczas każdej inicjalizacji bean’a dziedziczącego po „configParent”, podobnie do bean’ów z id’kami config1-config4.

Zdaję sobie sprawę, że dla niektórych ten wpis będzie równoznaczny z profanacją, ale ostatnio zastanawiałem się z której strony „ugryźć” problem przestawienia zależności w jednym projekcie na konfigurację spring’ową. Dlaczego – otóż nie miałem za bardzo pomysłu na zintegrowane rozwiązanie, obsługujące zależności w aplikacji w sposób kompleksowy, więc postanowiłem wybrać łatwiejsze rozwiązanie – wstawić xml’a, dorzucić jakiegoś prostego bean’a, a później to już pewnie jakoś pójdzie, no ale dobrze by było zacząć od początku.

Na pierwszy ogień wybrałem sobie plik konfiguracyjny. Poprzednia wersja aplikacji zawierała tekstowy plik konfiguracyjny w formacie zbliżonym do plików ini.

Na początek wyglądało to dość dobrze, bo trzeba było wpisać 2 rzeczy:

lista która to zawiera liste sekcji oddzielonych przecinkiem

– [sekcja1]




No i na pierwszy rzut oka to faktycznie ma sens, jednak po jakimś czasie okazało się, że to rozwiązanie dostarcza więcej problemów niż rozwiązuje a oto kilka z nich:

– zduplikowana konfiguracja – każde dodanie usunięcie sekcji wiązało się, z edycją wpisów w 2 miejscach

– mała elastyczność – zmiana opcji miejscami, w przypadku ich większej ilości to był koszmar

– małą czytelność w przypadku dużej liczby opcji

– brak wsparcia „ini with sections”  w javie – konieczność samodzielnego parsowania

No i zrodził sie pomysł zastąpienia tego xml’em springowym co w połączeniu z metodą getBeansOfType okazało się strzałem w dziesiątkę, tym bardziej, że opcje konfiguracyjne były już wczytywane do beana i dopiero później przekazywane dalej, więc jedyne co trzeba bylo zrobić to zdefiniować rodzica, podpiąć jary i już, oto przykład:

<!-- korzystam z <a href="">p namespace</a> -->


<bean class="sample.Bean" id="parent" abstract="true" p:commonProperty="sampleValue" />

<bean id="bean1" parent="parent" p:property="jakas wlasnosc" />