pgt » java

Java 5 – end of service

P.G.Taboada — Thu, 05 Nov 2009 12:38:15 +0000

End of Service Life für Java 5

Die 2004 mit großen Sprachänderungen eingeführte fünfte Java-Version hat letztes Wochenende das sogenannte “End of Service Life” (EOSL) erreicht. Sun empfiehlt, um auch zukünftig kritische Fehlerbehebungen zu erhalten, die Anwendungen entweder auf das neueste Update der Java Standard Edition (Java SE) zu migrieren oder den “Java SE Support for Business” in Anspruch zu nehmen, der bis zu 15 Jahre Gewährleistung für ältere Java-Versionen

W-JAX 2009 Vorträge

P.G.Taboada — Tue, 22 Sep 2009 09:54:21 +0000

W-JAX 2009

Die Konferenz für Java, Enterprise Architekturen & SOA

Die W-JAX ist die Konferenz für ganzheitliches technisches Know-how im Enterprise- und Webumfeld. Hier kommen die besten Experten Europas zusammen, um ihr Wissen und ihre Erfahrung an die Teilnehmer weiterzugeben. Durch ihren einzigartigen Mix an Themen verleiht die W-JAX alljährlich der Java Enterprise Community die entscheidenden Impulse.

Google Web Toolkit – Making a Better Web 2.0
Speaker: Papick G. Taboada

Mit Adwords und Google Wave sind die ersten großen GWT basierten Anwendungen von Google erschienen. Mit einem optimierenden Kompiler und pfiffige Codegeneratoren werden mit GWT maßgeschneiderte JavaScript Anwendungen erstellt, die Entwicklung findet allerdings in Java statt. In dem Vortrag werden Konzepte, Neuigkeiten aus 2.0 und die aus Adwords gewonnenen Architektur “Best Practices” vorgestellt.

SpringSource dm Server: Fitness für die Webanwendungen
Speaker: Agim Emruli, Papick G. Taboada

Java-EE-Webanwendungen tragen Deployment-bedingt eine große Menge an Bibliotheken mit sich. Mit OSGi werden dank einem standardisierten Modularisierungskonzept neue Wege gegangen. Lernen Sie in der Session die Möglichkeiten der Modularisierung in Java-EE-Webanwendungen auf dem OSS SpringSource dm Server kennen, damit schwergewichtige und monolithische Deployments der Vergangenheit angehören.

EDA in der Businessintegration
Speaker: Christian Dedek, Papick G. Taboada

Integrationsszenarien mit ereignisgesteuerten Architekturansätzen in Java umsetzen? Dieser Vortrag bietet Ihnen eine Einführung in EDA und Complex Event Processing (CEP) und stellt den Zusammenhang zwischen EDA und SOA her. Darüber hinaus veranschaulicht er die Architektur und den Aufbau von Esper und zeigt CEP-Einsatzszenarien.

How to use the SimpleHttpInvokerServiceExporter

P.G.Taboada — Thu, 26 Feb 2009 12:15:04 +0000

The JRE 1.6 ships with small HTTP-Server implementation. The Javadocs can be found here.

Spring has provides many different ways of configuring remote access to beans (aka spring remoting), but the remoting documentation fails when it comes to the usage of the HTTP Service exporter that works with the new JRE 1.6 HttpServer.

So here is a small example on how wire up the embedded JDK HttpServer and spring remoting.

First we need some service that we would like to expose as a remote service. For this short example I am using an very simple “EchoService” as follows:

The interface:

package x.y;
 
public interface EchoService {
	public abstract String echo(String message);
}

and some implementation:

package x.y;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
 
@Service("echoServiceLocalImpl")
public class EchoServiceImpl implements EchoService {
 
	private static final Logger log = LoggerFactory
			.getLogger(EchoServiceImpl.class);
 
	public String echo(String message) {
		log.info("Echoing: " + message);
		return message.toUpperCase();
	}
}

As you can see in the implementation, I am using annotation based configuration in this example.

That is pretty much all implementation I need to provide the services. Now I have to setup the HttpServer and configure the service exporting. The HttpServer implementation provided by the JRE uses factory methods for the setup. It is a pain to configure beans using factory-methods in the spring xml, and that’s why we usually create a FactoryBean to wrap up the ugly initialization of a bean. Fortunately we do not have to do this ourselves, the Springframework already provides (since version 2.5.1) such a factory bean.

So here is the context xml configuration file I am using to start the server and to export the services:

 
 version="1.0" encoding="UTF-8"?>
 xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
		http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:util="http://www.springframework.org/schema/util">
 
 
	 />
	 base-package="x.y" />
 
	 id="httpServer" class="org.springframework.remoting.support.SimpleHttpServerFactoryBean">
		 name="contexts">
			>
				 key="/echoService">
					 class="org.springframework.remoting.httpinvoker.SimpleHttpInvokerServiceExporter">
						 name="serviceInterface" value="x.y.EchoService" />
						 name="service" ref="echoServiceLocalImpl" />
					>
				>
			>
		>
		 name="port" value="2345" />
	>
 
	 id="remotedEchoService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">  
		 value="remoted" />
		 name="serviceUrl" value="http://localhost:2345/echoService" />
		 name="serviceInterface" value="x.y.EchoService" />
	>
>

As you can see I also added the xml snippet required for the clients that will be using the remoted service. The qualifier will help me to get the remoted instance and not the local one, hence both instances are kept in my application context in this sample. A simple testcase would look this way:

package x.y;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
 
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(inheritLocations = true, locations = { "classpath:/META-INF/beans.xml" })
public class TestRemoting extends AbstractJUnit4SpringContextTests {
 
	@Autowired(required = true)
	@Qualifier("remoted")
	private EchoService echoService;
 
	@Test
	public void echoTestUsingConfiguredClient() throws Exception {
		String echo = echoService.echo("test");
		assertEquals("Echoed correctly", "TEST", echo);
		assertTrue("Should not be the implementation", !echoService.getClass()
				.equals(EchoServiceImpl.class));
	}
 
	@Test
	public void echoTestManually() throws Exception {
		HttpInvokerProxyFactoryBean proxy = new HttpInvokerProxyFactoryBean();
		proxy.setServiceInterface(EchoService.class);
		proxy.setServiceUrl("http://localhost:2345/echoService");
		proxy.afterPropertiesSet();
		EchoService echoService = (EchoService) proxy.getObject();
		String echo = echoService.echo("test");
		assertEquals("Echoed correctly", "TEST", echo);
		assertTrue("Should not be the implementation", !echoService.getClass()
				.equals(EchoServiceImpl.class));
	}
}

The first test method echoTestUsingConfiguredClient does use the bean in the spring context (autowired, using the qualifier to get the right instance), the second method echoTestManually creates a proxy bean manually.

Both of them use the remoted proxy and not the local service implementation during the test.

I used maven to setup the eclipse project and to manage my project dependencies.
The project can be downloaded here.

Analysing trends

P.G.Taboada — Tue, 22 Apr 2008 10:22:31 +0000

After Rod Johnson demonstrated “Job Trends” with indeed.com, here some nice tools…

GWT and JSF….

http://www.indeed.com/jobtrends?q=gwt%2C+jsf&l=

http://www.google.com/trends?q=GWT%2C+JSF&ctab=0&geo=all&date=all&sort=0

http://markmail.org/

Unfortunately markmail does not support comparison, you will have to do it by hand.

Artikel zu Java und Concurrency

P.G.Taboada — Wed, 20 Feb 2008 09:49:13 +0000

Steffen Schluff hat einen Artikel zum Thema Java und Concurrency geschrieben:

Der seit den 70er Jahren vorhandene Trend, dass jede neue Prozessor Generation eine deutliche Steigerung der Taktfrequenz mit sich bringt, beginnt langsam aber sicher abzuebben. Die Hardware Hersteller versuchen nun, ihr Glück in der Erhöhung der verfügbaren Anzahl Prozessoren je Chip zu finden. Dementsprechend wird sich auch die Softwareentwicklung über kurz oder lang an diese neuen Rahmenbedingungen anpassen müssen.

Die Programmiersprache Java hat mit Java 5 in Form der sogenannten Concurrency Utilities eine mächtige neue API dazugewonnen, die es Programmierern erlaubt, mit ganz neuen Voraussetzungen an die Entwicklung von Multithreaded Anwendungen heranzugehen. Der vorliegende Artikel zeigt auf, warum das Themenfeld in Zukunft an Bedeutung gewinnen wird und stellt die wichtigsten Inhalte dieser API vor.

Mehr gibt es hier zu lesen…