Loading...
 

Harezmi IT Solutions Blog

Published by ksevindik on 2016-04-12 ksevindik

There is always room for improvement in programming. After my initial post about configuring Vaadin in simple 6 steps, my friend indicated that we could use annotation based configuration to get rid of web.xml in our Vaadin configuration. Yes, he is right. It is possible to configure Vaadin with annotations. Let's see how it is;

Step 1: Add Servlet API dependency into your pom.xml, and update your project's configuration

<dependency>
	<groupId>javax.servlet</groupId>
	<artifactId>javax.servlet-api</artifactId>
	<version>3.1.0</version>
	<scope>provided</scope>
</dependency>

Step 2: Modify your HelloWorldUI as follows

public class HelloWorldUI extends UI {
	
	@WebServlet(urlPatterns={"/*"},asyncSupported=true)
	@VaadinServletConfiguration(ui=HelloWorldUI.class,productionMode=false)
	public static class ExtendedVaadinServlet extends VaadinServlet {
	}

	protected void init(VaadinRequest request) {
		Button btn = new Button("Click Me!");
		btn.addClickListener(new ClickListener() {
			
			public void buttonclick(ClickEvent event) {
				Notification.show("Hello World!");
			}
		});
		setContent(btn);
	}
}

Step 3: Remove or comment out VaadinServlet configuration in web.xml

Just remove
<servlet> and <servlet-mapping>
elements in web.xml we had added in our previous post.


Now restart your web container, and try to access http://localhost:8080/helloworld URL to see the result. It should work as before.

Published by ksevindik on 2016-04-10 ksevindik

We are highly satisfied with Vaadin UI Framework. I recommend it to anyone who are asking advice about what UI framework to use in their web applications. This article, however, is not about why we love Vaadin. It might be a topic for another article. I will try to show, in this article, how to start working with Vaadin from ground zero super fast. I decided to write about this topic after a message from one of my friends complaining about difficulty in finding his way through Vaadin Book and expressing his confusion about whether using any Vaadin plugin or IDE support is a must to start working with Vaadin. Let's start with step by step.

Step 1: Create a web project using maven webapp archetype

mvn archetype:generate -DgroupId=com.example.vaadin -DartifactId=helloworld -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Step 2: Import the project into your favorite IDE

I prefer to use Eclipse, but it should not matter whether you use IntelliJ or Netbeans. Just import the maven project you created in the previous step. The project should be ready to use within your favourite IDE after the import.

Step 3: Add Vaadin Dependencies into pom.xml of your project

Add following dependencies into pom.xml file of the project.

<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-server</artifactId>
	<version>7.6.4</version>
</dependency>

<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-client-compiled</artifactId>
	<version>7.6.4</version>
</dependency>

<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-themes</artifactId>
	<version>7.6.4</version>
</dependency>

Step 4: Write UI class in your project

Create a new package with name com.example.vaadin, and following class into it.

package com.example.vaadin;
import com.vaadin.server.VaadinRequest;
import com.vaadin.ui.Button;
import com.vaadin.ui.Button.ClickEvent;
import com.vaadin.ui.Button.ClickListener;
import com.vaadin.ui.Notification;
import com.vaadin.ui.UI;

public class HelloWorldUI extends UI {
	protected void init(VaadinRequest request) {
		Button btn = new Button("Click Me!");
		btn.addClickListener(new ClickListener() {
			public void buttonclick(ClickEvent event) {
				Notification.show("Hello World!");
			}
		});
		setContent(btn);
	}
}

Step 5: Configure web.xml file of your project

<servlet>
	<servlet-name>VaadinServlet</servlet-name>
	<servlet-class>com.vaadin.server.VaadinServlet</servlet-class>
	<init-param>
		<param-name>UI</param-name>
		<param-value>com.example.vaadin.HelloWorldUI</param-value>
	</init-param>
</servlet>

<servlet-mapping>
	<servlet-name>VaadinServlet</servlet-name>
	<url-pattern>/*</url-pattern>
</servlet-mapping>

Step 6: Deploy the project into web container and start it


Now you can deploy your project into web container configured in your IDE. I prefer tomcat, but It doesn't differ if you choose jetty or something else. Just type the url your application deployed in the container, e.g. http://localhost:8080/helloworld, and you should have seen the “Click Me!” button on the page.

Keep in mind that above steps are not enough to leverage all the features of Vaadin, however, it is sufficient enough to start working with Vaadin, and develop your server side UI components. You can add necessary pieces into your project once you need them, and it should be easier to add those pieces as you get more comfortable within Vaadin ecosystem.

Published by ksevindik on 2016-03-07 ksevindik

Yakın bir zamanda Beginning Spring isimli kitabımız üzerinden Spring öğrenmeye çalışan bir arkadaşımdan kitapta okudukları sonrasında kafasında beliren böyle bir soru geldi. Kendisine verdiğim cevap belki Spring ile çalışan veya çalışmaya başlayacak arkadaşların da işine yarayabilir düşüncesi ile buradan paylaşıyorum.

Spring ApplicationContext'e hangi sınıfları kullanarak hangi bean'leri oluşturacağını, bu bean'lerin özelliklerinin neler olacağını, bean'ler arasındaki bağımlılıkların bilgisini, ve diğer pek çok uygulama ile ilgili kabiliyeti tanımlamamız gerekiyor. Bu tanımlara "configuration metadata" adı veriliyor. Spring ApplicationContext runtime'da bu configuration metadata'yı işleyerek uygulamanın ihtiyaç duyduğu bean'leri yaratıyor, aralarında ilişkiler kuruyor ve diğer pek çok kabiliyeti hayata geçiriyor.

Configuration metadata farklı formatlarda tanımlanabilir. XML geleneksel yöntemdir, Spring ilk çıktığında sadece XML vardı. Diğer pek çok framework gibi Spring'de konfigürasyon bilgilerini (metadata) XML formatında dosyalardan okuyarak elde ediyordu. O zamanlar daha Java'ya annotation kabiliyeti de eklenmemişti. Java 1.5 veya 5 ile annotation kabiliyeti eklenince bu sefer framework'ler arasında konfigürasyon metadata tanımlama yöntemi olarak annotation kullanma furyası başladı. Spring'de bu dönemde XML'in yanına bir de annotation kullanarak bean tanımlama, bean'ler arasındaki bağımlılıkları enjekte etme gibi kabiliyetler ekledi.

Tabi burada Spring ekibi şunu da sağlamıştır. ApplicationContext metadata formatından bağımsız tutularak, ApplicationContext'i ister XML, ister annotation tabanlı konfigüre etmek mümkün kılınmıştır. Hatta bu metadata formatlarını bir arada aynı anda kullanarak da ApplicationContext konfigürasyonu yapılabilir. Ancak burada şuna da dikkat etmek gerekiyor. Annotation tabanlı konfigürasyon XML tabanlı konfigürasyonun bire bir kopyası veya alternatifi olacak seviyede veya kabiliyette değildir. Aslında annotation tabanlı konfigürasyon XML tabanlı konfigürasyonla birlikte kullanılacak, onu complement edecek biçimde şekillendi. Günümüzde Spring kullanan projelerde de XML ve annotation tabanlı konfigürasyonlar çoğunlukla birlikte kullanılır. Spring'e özel altyapısal kabiliyetlerin konfigürasyonu veya uygulama koduna ait olmayan sınıflardan bean tanımları XML ile yapılırken, uygulamaya özel sınıflardan bean tanımları ve bağımlılıkların enjeksiyonu ise @Component, @Service, @Repository, @Controller, @Autowire gibi annotasyonlar kullanılarak annotasyon tabanlı gerçekleştirilir.

Zaman içerisinde XML tabanlı konfigürasyonlarla ilgili type safety, refactor edilebilirlik, modülerlik, extend edilebilirlik gibi noktalarda eleştirilerden dolayı bu sefer de framework'lerde Java tabanlı konfigürasyon popülerlik kazandı. Spring'de bu akıma ayak uydurdu ve XML tabanlı konfigürasyon ile yapılan işlemlerin bire bir aynısını Java sınıfları, metotlar ve bunların üzerinde bazı annotasyonları kullanarak yapmayı sağladı. Doğalarından ötürü kullanım biçimlerinde, davranışlarında bazı farklar olsa da, Java tabanlı konfigürasyona XML tabanlı konfigürasyonun bire bir alternatifi diyebiliriz. Tabi Spring ekibi ApplicationContext konfigürasyonunu daha önceden metadata formatından bağımısz kıldığı için bu davranışı Java tabanlı konfigürasyonda da korumuştur.

Spring uygulamalarında aynı anda hem XML, hem @Component, @Autowire gibi annotasyonlar, hem de Java konfigürasyon sınıfları ile ApplicationContext konfigürasyonu yapmak mümkündür. Artık günümüzde Servlet 3 API'sindeki yeniliklerle birlikte hiç Spring XML dosyalarına ve web.xml dosyasına ihtiyaç duymadan Spring kabiliyetine sahip web uygulamalarının konfigürasyonu yapılabilmektedir.

Published by ksevindik on 2016-03-01 ksevindik

Recently I had a chance to spend some time reading about OData and experiment with Apache OLingo Project in order to understand what OData provides us with in terms of making our REST services more standardized and self discoverable. I also compared it with Spring Data REST Project, what are their similarities and differences, whether it would be meaningful to integrate OLingo with Spring REST, or what should be the scope of integration if possible.

OData is simply a data exchange protocol by definition, and it tries to operate over REST. As it is a data exchange protocol, it first starts with defining a metamodel called as entity data model (EDM). Within EDM, we first specify what are our entities, what attributes they contain, what associations exist between them, functions which can be performed over those entities and so on.

public class PetClinicEdmProvider extends CsdlAbstractEdmProvider {
@Override
	public CsdlEntityType getEntityType(FullQualifiedName entityTypeName) throws ODataException {
CsdlEntityType entityType = new CsdlEntityType();
entityType.setName(ENTITY_TYPE_NAME_VET);

CsdlPropertyRef idRef = new CsdlPropertyRef();
idRef.setName("id");


CsdlProperty id =  new CsdlProperty().setName("id").setType(EdmPrimitiveTypeKind.Int64.getFullQualifiedName());
CsdlProperty firstName = new CsdlProperty().setName("firstName")
		.setType(EdmPrimitiveTypeKind.String.getFullQualifiedName());
CsdlProperty lastName = new CsdlProperty().setName("lastName")
		.setType(EdmPrimitiveTypeKind.String.getFullQualifiedName());
CsdlProperty graduationYear = new CsdlProperty().setName("graduationYear")
		.setType(EdmPrimitiveTypeKind.Int32.getFullQualifiedName());

entityType.setProperties(Arrays.asList(id,firstName, lastName, graduationYear));
entityType.setKey(Arrays.asList(idRef));

CsdlNavigationProperty navigationProperty = new CsdlNavigationProperty();
navigationProperty.setName("Specialties"); //name of the navigation property
navigationProperty.setType(FQN_ENTITY_TYPE_SPECIALTY);
navigationProperty.setNullable(false);
navigationProperty.setCollection(true);
navigationProperty.setPartner("Vets");

entityType.setNavigationProperties(Arrays.asList(navigationProperty));

return entityType;
}
}


After creating EDM, it comes to write Processor objects to expose data and handle navigations between entities, perform CRUD operations or other functions/actions and data filtering through REST. We can easily say that Processor objects closely corresponds with RestController beans in Spring MVC REST. They handle incoming web request, extract information out of it and translate that OData specific information into a format so that current task can be delegated to business layer. After business layer returns, this time domain specific result data is translated back into the OData format and web response is generated by writing it as response body. That translator part as depicted in the below diagram is called as OData service gateway or gateway in short. It acts as a bridge between processor layer and service layer.

public class PetClinicEntityProcessor implements EntityProcessor {
@Override
public void readEntity(ODataRequest request, ODataResponse response, UriInfo uriInfo, ContentType responseFormat)
		throws ODataApplicationException, ODataLibraryException {
	// extract metadata from request uri
	List resourceParts = uriInfo.getUriResourceParts();
	UriResource uriResource = resourceParts.get(0);
	UriResourceEntitySet resourceEntitySet = (UriResourceEntitySet) uriResource;
	EdmEntitySet edmEntitySet = resourceEntitySet.getEntitySet();

	// extract query data from request uri to perform search
	List keyPredicates = resourceEntitySet.getKeyPredicates();

	// execute backend business logic, search for specific entity in this
	// case
	Entity entity = oDataServiceGateway.readEntity(edmEntitySet, keyPredicates);

	// create a serializer to serialize found entity
	ContextURL contextUrl = ContextURL.with().entitySet(edmEntitySet).build();
	EntitySerializerOptions options = EntitySerializerOptions.with().contextURL(contextUrl).build();
	ODataSerializer serializer = odata.createSerializer(responseFormat);
	SerializerResult result = serializer.entity(serviceMetadata, resourceEntitySet.getEntityType(), entity,
			options);

	// write serialized data into the response
	response.setContent(result.getContent());
	response.setStatusCode(HttpStatusCode.OK.getStatusCode());
	response.setHeader(HttpHeader.CONTENT_TYPE, responseFormat.toContentTypeString());
}
}


Image

Finally, you need to write an ODataServlet in which you bring those pieces together and handle current web request. ODataServlet, Processors and OData service gateway can be seen as composing a Controller layer altogether.

public class ODataServlet extends HttpServlet {
    
    private PetClinicService petClinicService = new PetClinicServiceImpl(new PetClinicDaoInMemoryImpl());
    
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		OData oData = OData.newInstance();
		ServiceMetadata serviceMetadata = oData.createServiceMetadata(new PetClinicEdmProvider(), new ArrayList&lt;&gt;());
		ODataHttpHandler handler = oData.createHandler(serviceMetadata);
		
		ODataServiceGateway oDataServiceGateway = new ODataServiceGateway(petClinicService);
		PetClinicEntityCollectionProcessor entityCollectionProcessor = new PetClinicEntityCollectionProcessor(oDataServiceGateway);
		PetClinicEntityProcessor entityProcessor = new PetClinicEntityProcessor(oDataServiceGateway);
		PetClinicPropertyPrimitiveProcessor propertyPrimitiveProcessor = new PetClinicPropertyPrimitiveProcessor(oDataServiceGateway);
		
		//handler.register(new DefaultDebugSupport());
		handler.register(entityCollectionProcessor);
		handler.register(entityProcessor);
		handler.register(propertyPrimitiveProcessor);
		
		handler.process(request, response);
    }
}


Image

The end result is just exposing domain/data model over REST in a standard format/structure. OData specification tries to act similar to WSDL/SOAP of REST world. We can actually say that OData is WSDL/SOAP of REST. In my experience, it seems that as WSDL/SOAP makes things too complex in XML based web services, same is true for OData in REST side. Although, it will help you expose your domain/data model in a standard format, and make it exchangeable among various clients and server, if your expectation from OData is just to create a standard REST API for accessing data, and performing operations over REST, OData will simply be an overkill.

Spring Data REST and OData/OLingo are competitors. They both are trying to achieve similar results but from completely different perspectives. As OData is totally data centric or data oriented, Spring Data REST, on the other hand, is function oriented. It would be meaningless trying to integrate OData/OLingo with Spring Data REST or Spring MVC REST so that Spring should totally be responsible in handling web requests, and operating on controller layer. OData as protocol, and Apache OLingo as implementation of it should be in complete control in handling web requests. However, OLingo can be integrated with Spring and leverage Spring Container's capabilities in a limited fashion. ODataServlet can be replaced with a Spring Controller which just handles any HTTP request and delivers it to OData Handler for further processing. Response is not written by Spring at all. OData service gateway can be made a Spring managed bean. That way, Spring managed service beans can easily be injected into it.

@Controller
public class PetClinicODataController {
	
	@Autowired
	private PetClinicService petClinicService;
	
	@RequestMapping
	public void handle(HttpServletRequest request, HttpServletResponse response) {
		//OData instance must be unique for each request/thread
		OData oData = OData.newInstance();
		
		ServiceMetadata serviceMetadata = oData.createServiceMetadata(new PetClinicEdmProvider(), new ArrayList&lt;&gt;());
		ODataHttpHandler handler = oData.createHandler(serviceMetadata);
		
		ODataServiceGateway oDataServiceGateway = new ODataServiceGateway(petClinicService);
		PetClinicEntityCollectionProcessor entityCollectionProcessor = new PetClinicEntityCollectionProcessor(oDataServiceGateway);
		PetClinicEntityProcessor entityProcessor = new PetClinicEntityProcessor(oDataServiceGateway);
		PetClinicPropertyPrimitiveProcessor propertyPrimitiveProcessor = new PetClinicPropertyPrimitiveProcessor(oDataServiceGateway);
		
		handler.register(new DefaultDebugSupport());
		handler.register(entityCollectionProcessor);
		handler.register(entityProcessor);
		handler.register(propertyPrimitiveProcessor);
		
		handler.process(request, response);
	}
}


Spring Data REST's choice to make REST API standardized and self discoverable is HATEOAS. Hypertext as engine of application state is an approach so that clients should be able to discover REST API by themselves via following HTML link tags returned from REST service calls. However, even with HATEOAS, everything is not explicitly defined and self discoverable by client applications without any external help. It is still needed for someone who will interpret returned links and prepare upcoming REST calls out of those link information. On the other hand, it is necessary to have a standardized approach or style applied throughout a REST API. That way, client side developers will easily understand and learn how to fetch, insert, update or delete data.

Published by ksevindik on 2016-02-17 ksevindik

Factory method pattern aims to encapsulate object creation process within a method. That's why it is called as factory method pattern. They can be created as either static or instance methods within a class. In Spring Application Framework, although it is possible to make use of static or instance factory methods to create Spring managed beans, Spring offers an interface FactoryBean for this purpose. It has following contract:

public interface FactoryBean<T> {
	T getObject() throws Exception;
	Class<?> getObjectType();
	boolean isSingleton();
}


Whenever we need to encapsulate an object creation logic, we just implement this interface and create the target object within getObject() method.

public class FooFactoryBean implements FactoryBean<Foo> {

	@Override
	public Foo getObject() throws Exception {
		return new Foo();
	}

	@Override
	public Class<?> getObjectType() {
		return Foo.class;
	}

	@Override
	public boolean isSingleton() {
		return true;
	}

}


getObject() method is in role of factory method in that case. getObjectType() method just returns type of the instance we are creating. isSingleton() says whether the object managed by the Spring is singleton or not. If it's singleton, that means getObject() returns always the same instance, and Spring Container can cache it.

Afterwards, we define our bean and give FQN of our FactoryBean implementation class instead of our target bean class as follows;

<bean id="foo" class="examples.FooFactoryBean"/>


During bootstrap process, Spring Container pays special attention to the bean definitions whose classes implement FactoryBean interface. Whenever it sees a FactoryBean class, it creates an internal bean from that class, but also invokes its getObject() method and make the returned instance as the actual bean. Therefore, following code block can be used to obtain a reference to the Foo object;

Foo foo = applicationContext.getBean(Foo.class, "foo");


However, sometimes you may need to access to the FactoryBean instance of "foo" bean instead. Spring provides a special operator "&" for this purpose. If you perform your bean lookup with "&foo", then ApplicationContext will return you the FooFactoryBean instance. It look similar to referencing addresses of variables in C! Another option to access FooFactoryBean instance is to perform lookup by type, as follows;

FooFactoryBean fooFactoryBean = applicationContext.getBean(FooFactoryBean.class);


Of course, above will only work, if there is only one bean definition of type FooFactoryBean in the ApplicationContext.

By default, beans defined in the Spring Container are initialized eagerly during bootstrap unless they are marked as lazy, and FactoryBean instances are, too. However, FactoryBean.getObject() method is not invoked until target bean is actually needed or accessed even its bean definition is kept as eager.
If you want your bean to be initialized even it is not accessed or injected into another bean, then you need to implement another interface from Spring Application Framework, which is called as SmartFactoryBean.

public interface SmartFactoryBean<T> extends FactoryBean<T> {
	boolean isPrototype();
	boolean isEagerInit();
}


SmartFactoryBean is actually a sub type of FactoryBean interface. It declares two methods. One is isPrototype(), which indicates returned instances from getObject() method are always independent from each other. That means, they are prototype in Spring terminology. The other method is what we seek for. isEagerInit() method can be used to indicate that target bean should be eagerly initialized during bootstrap.

Published by ksevindik on 2016-01-18 ksevindik

Spring documentation states that both autowire byType and constructor modes expect at most one bean definition in the ApplicationContext, so that it can be autowired into the depending bean. Here is the excerpt taken from Spring Reference Documentation Table 6.2. Autowiring modes;

byTypeAllows a property to be autowired if exactly one bean of the property type exists in the container. If more than one exists, a fatal exception is thrown, which indicates that you may not use byType autowiring for that bean. If there are no matching beans, nothing happens; the property is not set.
constructorAnalogous to byType, but applies to constructor arguments. If there is not exactly one bean of the constructor argument type in the container, a fatal error is raised.


However, they don't show exact behaviour if there are more than one bean in the ApplicationContext and name of one of those beans matches with the name of constructor parameter. Let's see what is the difference with the following code samples;

First, XML based configuration

public class Foo {
	private Bar bar;

	public void setBar(Bar bar) {
		this.bar = bar;
	}
	
	public Bar getBar() {
		return bar;
	}
}

<beans...>
	<bean id="foo" class="examples.Foo" autowire="byType"/>
	
	<bean id="bar1" class="examples.Bar"/>
	
	<bean id="bar2" class="examples.Bar"/>
</beans>


The above sample will produce following error as expected:

Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [examples.Bar] is defined: expected single matching bean but found 2: bar1,bar2


Now we change the Foo class so that Bar is to be injected as a constructor parameter, change autowire mode to constructor, and give a try;

public class Foo {
	private Bar bar;

	public Foo(Bar bar) {
		this.bar = bar;
	}
}

<beans...>
	<bean id="foo" class="examples.Foo" autowire="constructor"/>
	
	<bean id="bar1" class="examples.Bar"/>
	
	<bean id="bar2" class="examples.Bar"/>
</beans>


As expected, we got the same error as above;

Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [examples.Bar] is defined: expected single matching bean but found 2: bar1,bar2


Now, here comes the difference. When we add another name one of those two Bar beans with an element, for example, autowire="constructor" starts working! It injects the bean with name matching with the name of the constructor parameter.

<beans...>
	<bean id="foo" class="examples.Foo" autowire="constructor"/>
	
	<bean id="bar1" class="examples.Bar"/>
	
	<bean id="bar2" class="examples.Bar"/>

	<alias name="bar2" alias="bar"/>
</beans>


Practically, autowire="constructor" turns into "byName", in which it is stated that only bean with the matching name is injected. However, when we run the code with autowire="byType", it still gives the error as listed above.

Now, annotation based configuration


At this point, let's give annotation based configuration a try, and see what happens there as well.

@Component
public class Foo {
	private Bar bar;

	@Autowired
	public Foo(Bar bar) {
		this.bar = bar;
	}	
}

<beans...>
	<context:component-scan base-package="examples"/>
	
	<bean id="bar1" class="examples.Bar"/>
	
	<bean id="bar2" class="examples.Bar"/>

	<alias name="bar2" alias="bar"/>
</beans>


When @Autowired annotation is placed on constructor, it works as expected.

Now, I change the code so that autowire will be performed with setter injection as follows;

@Component
public class Foo {
	private Bar bar;
	
	@Autowired
	public void setBar(Bar bar) {
		this.bar = bar;
	}
	
	public Bar getBar() {
		return bar;
	}
}


I would expect it wouldn't work when @Autowired annotation is placed over setter method, but, it works!

Unfortunately, the result of xml based autowiring with byType mode prevents us from concluding that autowire byType and constructor modes give precedence to bean name - property/constrcutor parameter name correspondence when more than one bean of matching type found in the ApplicationContext. There is clearly a behavioural inconsistency between xml based and annotation based autowiring in Spring.

Published by ksevindik on 2016-01-16 ksevindik

Spring's transaction propagation rule SUPPORTS states that if there exists a transaction when the method is called, it should work within that transaction, otherwise it should work outside any transaction. Similarly, transaction propagation rule NOT_SUPPORTED states that if there exists any active transaction when the method is called, that active transaction should be suspended before method is run, and method should run outside any active transaction.

However, things work a bit odd when Spring transaction mechanism is used with Hibernate as persistence technology at the backend. First of all we should know that although transaction propagation is set as SUPPORTS or NOT_SUPPORTED, Spring still creates a logical transaction so that it can execute if there exists any registered TransactionSynchronization objects at the end of the method call. Another thing to know that, we also need an active physical Hibernate Transaction object if we want to use contextual session feature of Hibernate in our DAO objects, and actually problem starts here. If you use contextual session of Hibernate within your DAO objects by calling sessionFactory.getCurrentSession(), SpringSessionContext which is in charge of implementing contextual session capability within Spring environment, registers a SpringSessionSynchronization object when getCurrentSession() is called and switches Hibernate Session flush mode to AUTO if it is MANUAL unless transaction is marked as readOnly=true.

When method completes with success, TransactionInterceptor performs commit! Yes, that is correct, Spring transaction support performs a commit whenever method returns with success even no actual transaction exists. Although HibernateTransactionManager which is actually in change of managing transactions, won't commit as there is no actiual transaction, it still executes registered TransactionSynchronization objects consecutively. SpringSessionSynchroization, at this point invokes Hibernate Session flush, and our SQL DML statements are sent to DB. Unfortunately, Hibernate physical transaction commits when Session is closed, even though transaction.commit() is not invoked explicitly. Hence, our changes become permanent in DB.

This scenario is valid both for propagation SUPPORTS and NOT_SUPPORTED. One workaround is to mark transaction as readOnly=true. This causes Spring to set Hibernate Session flush mode to MANUAL, and no flush occurs during SpringSessionSchronization.beforeCommit() method call. The other one is to change transactionSynchronization behaviour of Spring's PlatformTransactionManager to ON_ACTUAL_TRANSACTION. If you change it so, Spring won't register any TransactionSynchronization object including SpringSessionSynchronization. In that case, you won't be able to use contextual session capability within your DAOs. Therefore, it is better to go with the first option, and DON'T forget to mark your transactions as readOnly=true if their propagation rule is either SUPPORTS or NOT_SUPPORTED on your service methods.

Published by ksevindik on 2016-01-11 ksevindik

In our book about Spring, we discuss about transaction management mechanisms available in the Spring Framework, namely declarative and programmatic transaction mechanisms. Inside programmatic transaction demarcation section, it is further explained that how programmatic transaction can be achieved using different methods. One of the ways programmatic transaction can be achieved is, using TransactionTemplate utility class provided by Spring itself. It is based on Template Method pattern which constantly emerges over several different parts of the Spring Framework to encapsulate steps of a recurring operation, such as data access, transaction management, REST or JMS communication logic etc. In that case, main transaction demarcation logic is fixed within the specific template method, but varying steps can be given into it later on, so that specifics of the algorithm can be customized by the calling body. In our case transactional code block which needs to be run within an active transaction is given as a method parameter.

TransactionTemplate tt = new TransactionTemplate(transactionManager);
tt.execute(new TransactionCallbackWithoutResult() {
        public void doInTransaction(TransactionStatus status) {
                entityManager.persist(pet);
        }
});


Recently, one of our book readers asked about whether mentioning about TransactionTemplate as an example of Template Method is really correct. He asked that shouldn't we call it as Strategy instead. Well, actually both Strategy and Template Method patterns are very similar in behavioural aspect. Indeed, we can call them as cousins with some slightly different characteristics. They both try to encapsulate an algorithm. However, they varies in how that encasulation is achieved.

Image


Strategy pattern encapsulates the algorithm using object composition or delegation. Subject depends on Strategy interface, and a concrete implementation of the Strategy is chosen and invoked based on decisions made at runtime. That way, specific algorithm which will be executed can be determined and changed dynamically. Context information of the client environment which might be consulted at during execution of the algorithm is usually passed in as method argument in the Strategy pattern.

public class AuthenticationProvider {
	private UserService userService;
	
	public AuthenticationProvider(UserService userService) {
		this.userService = userService;
	}

	public boolean authenticate(String username, String password) {
		User user = userService.loadUserByUsername(username);
		return user != null && user.getPassword().equals(password);
	}
}

public interface UserService {
	public User loadUserByUsername(String username);
}


In the above code sample, AuthenticationProvider depends on UserService in order to obtain User object through it. UserSerice, an interface, is in role of Strategy here, and it may have several concrete implementations, each of which queries User by username from different user realms. Any of those concrete implementations can be injected into AuthenticationProvider at runtime.

Image

On the other hand, Template Method pattern handles encapsuation of the algorithm and selection of it at compile time, usually based on inheritance. It fixes main steps of algorithm in a base class, called as Template Method class, and expects varying steps to be provided by the specific subclass which extends from the Template method class. Therefore, algorithm selection is finished long before app is running.

public abstract class QueryTemplate<T> {

	private DataSource dataSource;

	public void setDataSource(DataSource dataSource) {
		this.dataSource = dataSource;
	}
 
	public final List<T> execute() {
		Connection connection = null;
		PreparedStatement statement = null;
		try {
			connection = dataSource.getConnection();
			String sql = getSql();
			statement = connection.prepareStatement(sql);
			Object[] args = getArgs();
			for(int i = 0; i < args.length; i++) {
				statement.setObject(i+1, args[i]);
			}
			ResultSet resultSet = statement.executeQuery();
			List<T> resultList = new ArrayList<T>();
			while (resultSet.next()) {
				T record = process(resultSet);
				resultList.add(record);
			}
			return resultList;
		} catch (SQLException e) {
			throw new RuntimeException(e);
		} finally {
			if (statement != null)
				try {
					statement.close();
				} catch (SQLException e) {}
			if (connection != null)
				try {
					connection.close();
				} catch (SQLException e) {}
		}
	}

	protected abstract String getSql();
	protected abstract Object[] getArgs();
	protected abstract T process(ResultSet resultSet) throws SQLException ;
}


In the above code sample, QueryTemplate is a base class in which execute() method is implemented along with three other abstract methods which are called by the execute() method at specific steps during query execution process. Sub classes extending QueryTemplate override those abstract methods implementing expected behaviours within them. Clients don't need to know exact sub type during query execution, they simply depend on QueryTemplate to perform their task.

Inheriting Template method class is not the most effective way from a framework perspective to provide varying parts. In Java environment, it cannot be feasible as well, especially class which needs to extend from Template Method class is already extending from another class, hitting against multiple inheritance limitation. Instead, frameworks follow another way to feed Template Method with those varying steps; as method input arguments.

public class QueryTemplate<T> {

	private DataSource dataSource;

	public void setDataSource(DataSource dataSource) {
		this.dataSource = dataSource;
	}

	public final List<T> execute(String sql, RowExtractor<T> rowExtractor, Object...args) {
		Connection connection = null;
		PreparedStatement statement = null;
		try {
			connection = dataSource.getConnection();
			statement = connection.prepareStatement(sql);
			for(int i = 0; i < args.length; i++) {
				statement.setObject(i+1, args[i]);
			}
			ResultSet resultSet = statement.executeQuery();
			List<T> resultList = new ArrayList<T>();
			while (resultSet.next()) {
				T record = rowExtractor.process(resultSet);
				resultList.add(record);
			}
			return resultList;
		} catch (SQLException e) {
			throw new RuntimeException(e);
		} finally {
			if (statement != null)
				try {
					statement.close();
				} catch (SQLException e) {}
			if (connection != null)
				try {
					connection.close();
				} catch (SQLException e) {}
		}
	}

	public static interface RowExtractor<T> {
		public T process(ResultSet rs);
	}
}


That code sample shows variation in Template Method mentioned previously. QueryTemplate is concrete in this case, and RowExtractor is interface which declares a method to process each row in the ResultSet return from the query executed. Both query to be executed, query parameters if there exists any, and rowExtractor object are given as method parameters to execute method of QueryTemplate. That way, application code doesn't need to extend from Template Method class over and over again. It just calls the method in order to execute the algorithm, and passes varying steps as method arguments into it.

If the varying parts are code blocks that need to be executed at a specific point in the algorithm, the only possible way prior to Java 8 was anonymous classes. Some contextual information, like TransactionStatus in our TransactionTemplate example, can be passed in as method parameters of anonymous class similar to Strategy pattern as well. Probably, this variation in the implementation of the Template Method pattern causes some people to think that it more resembles to the Strategy pattern.

Published by ksevindik on 2015-11-13 ksevindik

Hibernate'in dokümante edilmemiş özelliklerden birisi de import.sql kabiliyetidir. Eğer root classpath'e import.sql isimli bir dosya eklerseniz ve bu dosya içerisine de SQL ifadeleri yazarsanız Hibernate şema export adımından sonra bu SQL ifadelerini çalıştıracaktır. Bu yöntem ile test veya development sırasında örnek verinin DB'ye eklenmesi mümkündür. import.sql kullanırken dikkat edilmesi gereken bir iki husus söz konusudur. Bunlardan birisi yazılacak SQL ifadeleri DB spesifik olacaktır. Diğeri ise import.sql'in çalıştırılabilmesi için hibernate.hbm2ddl.auto property değerinin ya "create" ya da "create-drop" olmasıdır.

Tabi Spring kullanıcıları için bu tür örnek veri populate etme kabiliyetleri çok primitif gelecektir. Spring tarafında jdbc:embedded-database veya jdbc:initialize-database gibi namespace elemanları ile bırakın uygulama düzeyinde veri yüklemeyi, test sınıflarına özel örnek veri yüklemek bile çok kolay bir iştir.

<jdbc:embedded-database id="dataSource">
    <jdbc:script location="classpath:schema.sql"/>
    <jdbc:script location="classpath:test-data.sql"/>
</jdbc:embedded-database>

<jdbc:initialize-database data-source="dataSource">
    <jdbc:script location="classpath:com/foo/sql/db-schema.sql"/>
    <jdbc:script location="classpath:com/foo/sql/db-test-data.sql"/>
</jdbc:initialize-database>
Published by ksevindik on 2015-11-12 ksevindik

ULAKBİM tarafından düzenlenen Kamuda Açık Kaynak Konferansı'ında Spring Framework'ü etraflıca tanıttığımız Spring Ekosisteminde Kurumsal Yazılım Geliştirme isimli bir sunum yaptık. Katılım oldukça yoğundu. Sunumu Spring, kurumsal uygulamaların özellikleri ve orta katman ihtiyaçları ile ilgili kısa bir bilgilendirmenin ardından demo ağırlıklı gerçekleştirdik.

12.11.2015 tarihinde ULAKBİM tarafından düzenlenen Kamuda Açık Kaynak kullanımı ile ilgili etkinlikte yaptığımız Spring Ekosisteminde Kurumsal Yazılım Geliştirme isimli sunumdan bir görüntü


Kurumsal Java Eğitimleri'mizde sürekli olarak kullandığımız petclinic örneği üzerinde sıfırdan bir Spring konfigürasyonu nasıl yapılır, en basit biçimde standalone ortamda Spring ApplicationContext nasıl yaratılır ve kullanılır ile başlayarak Spring'in sağladığı pek çok kabiliyeti adım adım örnekledik.

12.11.2015 tarihinde ULAKBİM tarafından düzenlenen Kamuda Açık Kaynak kullanımı ile ilgili etkinlikte yaptığımız Spring Ekosisteminde Kurumsal Yazılım Geliştirme isimli sunumdan bir görüntü


Bu örnekler arasında Spring ile entegrasyon birim testleri, JDBC ile veri erişim kabiliyetleri nelerdir, transaction yönetimi, servis metotları düzeyinde cache'leme ve validasyon kabiliyetleri, aspect oriented programlamada Spring'in sağladığı kolaylıklar, custom bir aspect'in yazılması ve çalıştırılması, standalone ortamda yapılan bütün bu konfigürasyonun web ortamına taşınarak uygulamanın çalıştırılması, MVC ve REST kabiliyetleri, Spring Security'nin form ve HTTP basic authentication kabiliyetleri mevcuttu. Katılımcılar 3 saate yakın süren oturum boyunca bütün bu özelliklere sahip kurumsal bir web uygulamasının Spring kullanılarak nasıl geliştirilebileceğini gözleme şansına sahip oldular.

20151112 ULAKBIM KAK Spring Framework Sunumu