pgt » Java & Co.

GWT-JSF – Wahl-o-Mat

P.G.Taboada — Thu, 05 May 2011 07:15:22 +0000

Die kleine Entscheidungshilfe, bzw. die Vortragsfolien zu unserem Vortrag auf der Jax 2011.

Oder direkt hier: http://bit.ly/gwt-jsf-wahlomat

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

Eclipse Galileo SR1

P.G.Taboada — Thu, 24 Sep 2009 16:42:55 +0000

I just started downloading the SR1 release of Eclipse Galileo. According to bugzilla, there were 241 bugs fixed with this release.

Can’t wait for the download to finish to check if Eclipse is working better on Snow Leopard…

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.

HTML Editor for Eclipse

P.G.Taboada — Mon, 21 Sep 2009 12:19:11 +0000

Thanks for the tip:

Amateras HTML Editor for Eclipse

EclipseHTMLEditor is an Eclipse Plugin for HTML / JSP / XML / CSS / DTD / JavaScript editing. This plugin is required by StrutsIDE and FacesIDE.

HTML/JSP/XML/CSS/DTD/JavaScript Highlighting

HTML/JSP Preview

HTML/JSP/XML Validation

Contents Assist

Wizards for creating HTML/JSP/XML files

And many more powerful features…

Works fine with Eclipse Galileo.
I am using it now along with the Google Eclipse Plugin for GWT development/ training.

Non invasive GWT and Spring integration (reloaded)

P.G.Taboada — Fri, 17 Jul 2009 20:14:22 +0000

New project layout

Here is my overdue update to my Non invasive GWT and Spring integration blog post from early 2008. Since then we have had the GWT 1.6 and GWT 1.7 releases:

One of the biggest changes to GWT 1.6 is a new project structure. The old output format has been replaced by the standard Java web app "expanded war" format, and the actual directory name does default to "/war". Note that the war directory is not only for compiler output; it is also intended to contain handwritten static resources that you want to be included in your webapp alongside GWT modules (that is, things you'd want to version control).

As a matter of fact, now we finally can (must) manage the web.xml file ourselves:

Projects with server-side code (GWT RPC) must configure a web.xml file at /war/WEB-INF/web.xml. This web.xml file must define and publish any servlets associated with the web application.

This is a little pain for really much gain, and that's why I am writing this post after all...

Starting a Springframework ApplicationContext in a Java EE compiient web-application is well known and documented in the Springframework reference:

 version="1.0" encoding="UTF-8"?>

    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
 
>
	>
		>contextConfigLocation>
		>/WEB-INF/spring-conf.xml>
	>
	>
		>log4jConfigLocation>
		>/WEB-INF/log4j.xml>
	>
	>
		>org.springframework.web.util.Log4jConfigListener>
	>
	>
		>org.springframework.web.context.ContextLoaderListener>
	>
 
	
 
	
 
 
>

There aren't many beans in my spring configuration files as I am using annotation based configuration in my apps. Here a sample spring confuguration taken from one of my sample projects:

 version="1.0" encoding="UTF-8"?>
 
    xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="
	     http://www.springframework.org/schema/beans     http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
         http://www.springframework.org/schema/context  http://www.springframework.org/schema/context/spring-context-2.5.xsd
    "
	>
 
	 />
	 base-package="x.y.gwt.hellospring.server" />
 
	 id="basicTextEncryptor" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
		 name="algorithm" value="PBEWithMD5AndDES" />
		 name="keyObtentionIterations" value="1000" />
		 name="password" value="s0990w8eh0c8hf08aefh8hGf9egf9aefea8f" />
	>
 
>

So this is (despite of the missing log4j.xml config) the configuration setup I am using on GWT 1.6 and GWT 1.7 projects in order to bootstrap an application context.

The next step is to implement the dependency injection of spring managed beans into my GWT RPC serverside implementation. I will be using the annotation based config provided by the Springframework.

This is how the dependency injection in my GWT RPC services looks like:

/**
 * The server side implementation of the RPC service.
 */
@SuppressWarnings("serial")
public class EncodingServiceImpl 
extends AutoinjectingRemoteServiceServlet
implements EncodingService {
 
	private IEncodingService encodingService;
 
	@Autowired
	@Required
	public void setEncodingService(IEncodingService encodingService) {
		this.encodingService = encodingService;
	}
 
	// Service implementation ommited here...
 
}

EncodingServiceImpl is the server side GWt RPC implementation, while EncodingService is the GWT service I am setting up. The managed bean in my spring configuration implements IEncodingService (and uses the great jasypt lib). I am using the annotations to configure the dependency injection.

All I have to do now, is "autowire" my RPC servlet during initialization. Since this is not going to be the only GWT RPC service needing dependency injection I introduced the AutoinjectingRemoteServiceServlet class:

public class AutoinjectingRemoteServiceServlet extends RemoteServiceServlet {
 
	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		WebApplicationContext ctx = WebApplicationContextUtils
				.getRequiredWebApplicationContext(config.getServletContext());
		AutowireCapableBeanFactory beanFactory = ctx
				.getAutowireCapableBeanFactory();
		beanFactory.autowireBean(this);
	}
 
}

There is not much to say about this class. During the initializiation of the RPC Servlet (remember: GWT uses servlets as the foundation technology on the server side implementation of GWT RPC. Being so, the GWT RPC service implementation "lives" in the same lifecycle as any other servlet. I am using the initialization step to get a reference to the ApplicationContext. After that I use the autowire bean method to autowire the servlet automatically.

If you prefer to directly expose spring beans, you should have a look at http://code.google.com/p/spring4gwt/.

Compiler-Warnings. Mal hü, mal hott?

P.G.Taboada — Thu, 09 Jul 2009 08:55:10 +0000

Ich habe in Eclipse 3.4.2 unter “Compiler” “Errors/ und Warnings” folgende Einstellungen:

Es geht mir um die Einstellung “Type parameter hides another type“.

Folgerichtig bekomme ich an diesem Codeschnipsel ein paar Warnungen:

Und so lautet die Warnung:

Was ja im Prinzip richtig ist, aber gewollt, schliesslich verwende ich ja “this.” in meiner Methode um an die Instanzattribute zu kommen. Ich arbeite ungerne mit Unterstrichen in Variablennamen (in etwa so: _invokedMethod) und die Unterscheidung zwischen lokalen Variablen und Instanzvariablen wird über die Referenz deutlich.

Immerhin (oder seltsamerweise?) wird diese Warnung nicht bei Setter-Methoden angezeigt, dort wird es geduldet:

Sehe keinen Sinn darin, so eine Warnung zu bekommen und würde spontan in den Compilereinstellungen hier auf “Ignore” umstellen, zumindest solange meine Parameter einer nicht Setter-Methode so heissen wie meine Attribute. Ich sehe ja vor lauter Wellen das Meer nicht mehr!

Denkfehler?

—

Es gibt eine bereits viel sinnvollere Warnung, und zwar wenn ich “this.” nicht benutze. Dann aber auch in der Zeile meiner Zuweisung… So wird die sinnlose Zuweisung im Code angezeigt:

Das ist auch gut so. Hier noch die Warnungen die man an dieser Stelle bekommt:

Das ist eine Sinnvolle Warnung und sollte IMHO von Warning auf Error umgestellt werden.

Freue mich auf Kommentare!

SpringSource Produktivitätsoffensive

P.G.Taboada — Sat, 09 May 2009 09:11:19 +0000

Diese Woche haben wir zwei großartige Nachrichten aus der SpringSource Ecke bekommen:

STS

Bei STS handelt es sich um eine Eclipse-basierte IDE, die bisher nur den “Enterprise- Kunden” vorbehalten war. Es ist die Zusammenstellung von Spring IDE und andere Plugins aus der SpringSource Softwareschmiede:

Key Highlights von der Produktseite:

Greater Productivity

OSGi Made Easy

Developer Onramp to Virtualization

Task Focused Development

Guided Learning

Bei Spring Roo handelt es sich letztendlich um die Umsetzung von Rod Johnsons Aussage:

“We (the Java EE Community) are not picking the low hanging fruits“

Und damit hat er recht: wir haben mit Java EE sehr mächtige Frameworks, scheitern aber kläglich daran, daraus ordentliche “full stack application frameworks” zu bauen. Die Quittung haben wir mit “Ruby on Rails” und Konsorten bekommen: erst haben wir sie belächelt, dann diese für Prototypen eingesetzt. Jetzt lautet es “success stories” aus allen Ecken. Mit Spring Roo bekommen wir ein “full stack application framework“, das diesmal aber in Java mit Java Tools und Technologien umgesetzt wurde (Maven2, JPA, JUnit, Spring MVC, Spring Security, u.s.w.).

“Roo delivers productivity without compromise. Spring Roo melds the development advantages that have emerged in dynamic frameworks with the robustness, reliability, performance and familiarity of enterprise Java. Roo is designed for developers that want to build Java applications faster than ever without having to learn a new language or syntax. Roo is designed to be incorporated into the majority of development environments including visual development tools and utilizes the widely understood implementations of relevant standards.” (Quelle: http://www.springsource.org/roo)

Die Spring Roo Seite verrät zur Zeit sehr wenig – nicht einmal, wie man Spring Roo aktuell runterladen kann. Hier muss man die Blogosphäre aus dem Umfeld im Radar haben:

Ich habe das Gefühl, dass die Java-Gemeinde endlich aufatmen kann, denn jetzt hat man eine Alternative zu Ruby on Rails, Grails und Co. Es wird sich zeigen, wie tief Spring Roo in den Kinderschuhen steckt, und ob SpringSource “den Kampf” an einer weitere Front aufnehmen kann. SpringSource scheint wieder die OSS Community entdeckt zu haben (die Community darf sogar bei der Namensfindung mithelfen), und spielt zu meiner Freude die Karte gross aus.

Java in den Wolken

P.G.Taboada — Thu, 23 Apr 2009 22:53:40 +0000

May we live in interesting times…

again…

and again…

It's cloudy and I can't see the sun...

Wenn das nicht mal spannende Zeiten. Erst vor ein paar Tagen (7. April) kommt Google völlig aus dem Nichts heraus und überrascht mit einem 3-fach Release: GWT 1.6 (ok, das war nicht überrraschend), Java auf der GAE (Google Application Engine) und dazu noch das passende Plugin, damit auch alles schön aus Eclipse heraus benutzt werden kann.

“Hui”, dachte ich…

Wäre da nicht “IBM will Sun kaufen” (Heise Meldung vom 18. März), dann doch nicht (Heise Meldung vom 6. April), dann schnappt plötzlich Oracle zu (Heise Meldung vom 20. April) – dann hätten wir sicherlich viel länger über Java und GAE gesprochen. Aber die vielen offenen Fragen (Java, JCP, Openoffice, MySQL, Sparc), prominente Meinungen (hier und hier) und Reaktionen rund um Suns Zukunft (oder Javas Zukunft) haben alles überdeckt. Irgendwo habe ich noch ein Kommentar aufgeschnappt: “Google hat im Cloud-Geschäft Amazon ein Bein abgebissen”. Ob es jetzt ein Bein oder ein Finger war kann ich nicht sagen, aber ich finde die Metapher gut und da will ich drauf aufbauen…

Oracle hat doch jetzt den eigenen Java EE Appserver, Glassfish und zeigte bereits Interesse (Heise Meldung vom 24. März) an Red Hat (und damit auch an JBoss) – alle zusammen durchaus nennenswerte AppServer. Oh, und ja, auf der anderen Seite, im Schatten der Nachrichten haben wir noch Amazon (ohne Bein) und IBM (mit einem AppServer den sie nur noch “über Bande” verkaufen wollen und Geronimo aka Websphere Community Edition).

Tja – und heute kommt die nächste Nachricht. Amazon (AWS) bietet jetzt IBM Produkte im Elastic Cloud (EC2) an. Irgendwie bietet sich die Metapher an, dass Amazon jetzt mit schicken neuen Krücken los humpelt. Und das ist eine böse Metapher und die will ich gar nicht laut gedacht haben.

“Seufz”, denke ich.

“Es bleibt spannend!”

Weitere Links zum Thema und Blogs die ich regelmäßig lese:

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.

Jira Plugin & Log4J

P.G.Taboada — Wed, 25 Feb 2009 10:48:00 +0000

I came across this problem lately when I was working on a Jira plugin. A Jira plugin does not rely on a OSGi container or some similar plugin framework. The plugin consists mainly of a jar file that gets deployed with (I mean inside…) the Jira Java EE web application.

Logging is an issue in such an environment: the surrounding application configures the logging API – there is no way to provide log4j configuration fragments.

The best way I found to solve the problem was (again) to use the native logging API to the configuration manually. Since Jira has already setup the logging API, all I needed was to add some categories with some levels, or, if I need to, create my own appenders. That’s all possible with the API exposed by log4j.

So I created a Jira component module inside my plugin that does the configuration magic. Jira uses PicoContainer (lightweight, embedable, configurable, POJO based IOC/DI component runtime) as the runtime for their own and for components provided by plugins. As components get initialized along with the Jira application it is good place to implement the required logging configuration:

package x.y;
 
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
 
public class LogConfigurationComponent {
 
	private static final Logger LOG = Logger.getLogger(LogConfigurationComponent.class);
 
	public LogConfigurationComponent() {
 
		Level level = Level.toLevel("DEBUG");
		Logger logger = Logger.getLogger("x.y.somethingcool");
 
		Level oldLevel = logger.getLevel();
		logger.setLevel(level);
 
		String message = "Changing loglevel for logger "
				+ logger.getName() + " from " + oldLevel.toString()
				+ " to " + level.toString();
 
		LOG.info(message);	
	}
}

Just by adding this component to the atlassian-plugin.xml in my plugin I solved my problems with distributed logging configuration:

 key="x.y.coolthings"
	name="CoolThings">
	>
		>Simple plugin>
		>1.0>
		 name="PGT Technology Scouting" url="http://www.pgt.de" />
	>
 
	 key="logConfig" name="The logging configuration for this plugin"
		class="x.y.LogConfigurationComponent">
	>
	
>

Stop this “my support is better than yours” discussion!

P.G.Taboada — Sat, 30 Aug 2008 10:46:07 +0000

Ok, someone is making money with support.
Ok, someone is not contributing to OSS.
But wait – is offering support not exactly that? Contributing to OSS by doing the dirty work no one wants to do?

That’s why I do not agree entirely with the label “parasites”. It is not easy to offer support, IMHO it is a Job that no one likes to do. I don’t know if it is true for everyone – but I am very happy to be a developer and not to be a support guy.

It just happens that it is exactly this job is actually needed, and hence, can be monetized.

Don’t tell me that those few developers really contributing to an OSS project have time to provide support as it is required today.
Don’t tell me that somebody not contributing is not capable to offer support. If you really believe that, you don’t understand what it means to offer support.
Don’t tell me that developers can offer better support.

So even if all OSS developers start working 24h a day (I am sure many already do) – would they be supply enough service to cover the demand? How many people do need support, now many contributors do we have?

I remember reading somewhere on a OSS page: “great support by the community”. What does this mean? Easy to tell: we can’t or we won’t offer support.

I believe that neither Spring nor any other OSS product would have come that far without the many consultants and supporters we have working very hard today. So someone is monetizing support? Fine! It will open the doors for enterprise OSS acceptance. Is someone offering training for OSS technologies? GREAT!

Does it feel like it is stealing work? No it is not.

Sure – we live in interesting times. Don’t have a working business plan for your successfull OSS product? I tell you what: go offer support for it. But be warned: it is hard work, it is mostly badly payed, it does not scale, and you will stop working with computers and start working with people.

Good luck!

GWT – kein JSF wie Andy Bosch es haben will…

P.G.Taboada — Tue, 20 May 2008 08:02:40 +0000

Danke Andy für dein Kommentar. Freut mich, dass dich mein provokanter Titel in die Session gezogen hat – das war Absicht. Und es freut mich um so mehr, dass Du dir die Zeit genommen hast, ein Kommentar zu schreiben. Also auf gehts, möchte kurz auf dein Kommentar eingehen:

Um jedoch ehrlich zu sein: Ich finde die Ansätze von GWT durchaus interessant, allerdings bleibe ich doch bei meiner gewohnten JSF-Entwicklung.

Klar…

Ich befinde mich im Web und programmiere auch dort. Warum muss ich das zwanghaft zu verbergen versuchen?

Was meinst du mit verbergen? Und was meinst du mit du programmierst im Web? Sowohl GWT als auch JSF definieren ein Komponentenmodell und abstrahieren von der klassischen request/response Entwicklung. Sowohl bei JSF als auch GWT hat der Entwickler wenig Kontakt mit den ursrpünglichen Web-Technologien (wann habe ich das letzte mal ein Tree von Hand in HTML geschrieben?)-

So gesehen programmierst Du nicht im Web, oder ich habe dich falsch verstanden. Weder JSPs noch das Facelets-XML sind im eigentlichem Sinne Web-Technologien, diese werden nämlich vom W3C definiert…

Auch bietet mir GWT meiner Meinung nach nicht wirklich neuartige Antworten auf Dinge, die ich in JSF nicht genauso gut lösen könnte (nur eben anders).

Das stimmt nicht. Ich kenne beide. Du nicht. Aussage gegen Aussage.

Auch in JSF gibt es einen großen und sehr guten Komponentenmarkt, der mir die Details von Html und JavaScript versteckt.

Und genau hier greift eines meiner Kritikpunkte: JSF ist kein Produkt, nur ein Standard. Die Komponenten sind teilweise inkompatibel zueinander, haben unterschiedliche Programmiermodelle, etc.

Auch habe ich keine Antwort gefunden, warum ich von einem Standard wie JSF weggehen sollte, nur um eine proprietäre und nicht standardisierte API zu verwenden.

Ja, JSF ist ein Standard. Ich weiss noch, wass ich von dem EJB Standard gewonnen habe: 3 Mal die Anwendung portieren. Bei JSF sieht es auch nicht besser aus – oder kannst du unter Websphere einfach so beliebige Komponenten und JSF Implementierungen laufen lassen? Was bringt mir da der Standard? Trägheit?

Sicherlich ist Google mit seiner Marktstärke durchaus in der Lage, auch einen eigenen “Standard” in die Welt zu setzen, aber ich setze eher auf die im Java-Umfeld etablierten Standardisierungsprozesse wie den JCP (trotz aller Kritik an ihm).

Kann ich nachvollziehen und als Argument stehen lassen. Ich habe mich mehr den technischen und konzeptionellen Themen in meiner Session gewidmet.

Eine Entscheidung, welches Framework man zukünftig nutzen möchte, muss jedoch jeder selbst treffen.

Genau. Daher ist eine Gegenüberstellung der unterschiedlichen Webframeworks um Java Umfeld mit Sinn und Verstand wichtig. Ob man dann andere Frameworks einsetzt, oder nur daraus lernt – das wird die Zeit zeigen.

Für mich war die Session sicherlich dahingegend hilfreich, um mehr über GWT zu erfahren. Aber auch, um für mich die Frage beantworten zu können, ob GWT wirklich das bessere JSF ist oder der Titel einfach nur etwas provokant gewählt wurde.

Der Titel war erstens provokant und zweitens eine Fragestellung. So wie es aussieht habe ich es genau richtig gewählt – es hat dich in die Session gelockt und dich zum nachdenken gebracht.

Aber, ein paar Fragen habe ich an Dich…

Was ist wenn weder JSF noch GWT ein Standard wären? Würdest du dann mit JSP/ Servlets entwickeln?
Was ist wenn Struts der Standard geworden wäre? Wa würdest du dann nehmen?
Was ist wenn ich GWT benutze, um bessere JSF Komponenten zu schreiben

Würde mich freuen, von dir zu hören!

Modular apps with JBoss???

P.G.Taboada — Tue, 06 May 2008 10:54:19 +0000

Reading MarcF blog I stumbled across this statement:

enough to call it out for what it is “an emperor has no clothes” attempt to monetize his ISV base. I will respectfully point out that all this mumbo jumbo about modularity being a “quantum leap to the next generation” is just bullshit. We were peddling modular application servers with JBoss and its JMX base back in 2000, except we had real run-time substance behind it.

Funny. I understand the “run-time substance” point, won’t argue here. I agree that JBoss was/is a beautiful piece of work, modularity already implemented back in 2000.

Yes. But we, who did develop applications on top of this runtime, who tried to use standards (regarding Java EE specs), did not have ways of modularization. We had different component models, yes. People are using OSGi to split their own application into coarse grained modules. OSGi by hand is a pain in the ass. The platform helps here. So this is runtime, yes. And they are solving problems that maybe JBoss had back at 2000, and some people who are trying to use OSGi now.

I do not see Java EE solving that. I do not see Java Dynamic Modules beeing released, I do not see that becoming part of Java EE.

SpringSource announces an application plattform

P.G.Taboada — Mon, 05 May 2008 07:51:54 +0000

SpringSource recently announced the Spring Aplication Platform, and this announcement is generating a lot of fuss. Google has recently launched the Google App Engine. From an Java enterprise developers point of view it is shamelessly easy to use, deploy, etc. Well, unfortunately it only takes Python apps for now, but it is stated that there will be more languages supported in the future. But it’s Google again putting its finger into the Java EE wound (first GWT with webapps, then Android shaking the Java ME world, and now App Engine showing how runtimes should look like).

Looking at Googles App Engine I thought how nice it would be to have the deployment, packaging and runtime of Java EE applications redesigned. Those deployment descriptors really suck. As it seems (heard it at the Jax from speakers “off the record”) Java Dynamic Modules and Java Superpackages aren’t going to make it into the next Java relase – Java 7.

From this point of view, the Spring Application Platform is bringing fresh air into the Java EE development. The Java EE dream of a runtime didn’t come through. Modularization got lost somewhere in the way. Packaging and deployment is a nightmare, and tools didn’t solve the problem. Since Java EE 5 is being adopted very slowly and Java EE 6 is really far away, this is surely the best time to drop in an alternative. Well done. Though beeing an alternative, there seems to be some level of commitment regarding Java EE deployment support.

IMHO the real shock came with the change in licensing terms. We are used to SpringSource licensing their products under the Apache 2 license. The license is clear and accepted by most companies. The Spring Application Platform is licensed under the GPL. GPL is, IMHO, the most misunderstood license we have in the OSS. I do not have nothing against the GPL, I only have a problem with the different interpretations. And if a license can be misunderstood, how can we rely on it? I won’t start another blog about how GPL works – please go read the GPL and the GPL FAQ, it’s worth it. A nice reply from Will Hartung about GPL on the TSS thread can be found here.

Does nobody actually, you know, READ these licenses?
Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to “the community”.
I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying “I want the code, it’s GPL! Give me the code!” and I can nod and smile knowingly and tell you to pound sand. “Give me $100K and I’ll give you the software.

Thanks Will. It’s beautiful.

Rod argues that if someone takes the code, makes changes and starts selling it, this someone will, sooner or later, have to provide the source code to a major number of customers and hence the changes will be available for the community, especially for SpringSource. Rod, I hope I did quote you right, sorry if I didn’t.

Another great statement from Will comes a few postings later:

But you certainly aren’t going to take back contributions that don’t have at least shared copyright, because as soon as that happens you can’t relicense the whole under something other than GPL. So, there’s not a whole lot of value to the community there.

Later Rod makes a nice statement about what’s ok:

1. Using the platform to run closed source applications is OK. This immediately covers the vast majority of companies and developers who are end users. This would cover for example, software use by companies like Google, banks, media companies etc.
2. Modifying and extending the platform and “hiding” (closing) it is OK, unless you redistribute. So if you modify it in your own company, or you modify it and distribute your modifications in GPL open source, that’s OK. If you modify it and distribute a closed source product including those modifications, that is not OK. This would exclude Oracle, for example, from modifying the server and redistributing it as a closed source product. We believe this is a Good Thing.
3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.

I liked this one too:

Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law!!! ha ha
Lets stay technical please, even though it clearly doesn’t pay !!!

This is perfectly showing how GPL, although commonly used in OSS projects, is really badly misunderstood by people.

IMHO GPL licensing was a bad idea. SpringSource targets the enterprise, the enterprise dislikes GPL, that’s a fact. Linux seems to be the exception to the rule. It’ nice to see how SpringSource understands GPL – but this understanding is not binding. What if someone wakes up next week and says – “oh sorry, I think we have to rethink our GPL understanding….”

Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität

P.G.Taboada — Mon, 28 Apr 2008 09:00:04 +0000

Was habe ich mich gefreut, als Jira das Sicherheitskonzept um Rollen (Projekt-Rollen) erweitert hat. Statt Rechtekonfigurationen an Benutzergruppen zu binden, hat man jetzt die Möglichkeit Rechte an bestimmte Rollen zu binden. Für jedes Projekt folgt dann die Benutzer/ Rolle Zuweisung: dadurch ergibt sich letztlich, welche Rechte ein Benutzer für ein bestimmtes Projekt haben wird.

Gerade in kleine, agil arbeitende Teams ist das wesentlich effizienter: in einem Projekt ist man der Projektleiter, bei einem anderem lediglich ein Entwickler. So flexibel wie Entwickler heute die Rollen wechseln müssen, so flexibel konfigurierbar muss heute auch unternehmenskritische Software sein. In der Vergangenheit musste man in Jira für jede mögliche Kombination der Rollen in einem Projekt entsprechende Benutzergruppen einführen. Benutzergruppen sind aber statisch/ global und nehmen keine Rücksicht auf besondere Projektgegebenheiten. Am Ende bekommt jedes Projekt eigene Benutzergruppen.

Die Einführung von Projektrollen und Sicherheitskonfigurationen für Projektrollen im Allgemeinen reduziert die Konfiguration drastisch. Danke Atlassian!

Ein Rollenmodell ist nicht mit den heute üblichen deklarativen Mitteln konfigurierbar. Wir scheitern an der instanzbasierten Sicherheit. Je nach Projekt hat der Benutzer andere Rollen. Um so wichtiger ist es, ein Security Framework zu wählen, mit dem man die nötige Flexibilität und die Möglichkeit bekommt, eigene Anforderungen umzusetzen.

Auch wenn JAAS ein beeindruckendes Werk ist, mangelt es meiner Meinung nach an Flexibilität. Anpassungen sind sehr schnell nicht mehr portabel, eine Bindung zu der Laufzeitumgebung und oder Infrastruktur ist das Ergebenis. Spring Security (formerly known as Acegi) ist hingegen sehr flexibel. Security wird dadurch nicht trivial, aber besondere Anforderungen und entsprechende Lösungsansätze scheitern nicht mehr an dem Framework.

Schade dass in der Spring Security Dokumentation zu diesem Thema nichts zu finden ist. Eine Interessante Ausarbeitung zum Thema Gruppen und Rollen auf Konzeptebene ist hier zu finden.

Session: Complex Event Processing with Esper

P.G.Taboada — Sat, 12 Apr 2008 08:22:36 +0000

Last but not least – my presentation slides for my EDA, CEP, ESP and Esper session at the JAX India 2008. Thanks to all audients for visiting my presentation and for the interesting chats afterwards.

Complex Event Processing with Esper

Complex Event Processing, or CEP, is technology to process events and discover complex patterns among multiple streams of event data. ESP stands for Event Stream Processing and deals with the task of processing multiple streams of event data with the goal of identifying the meaningful events within those streams, and deriving meaningful information from them. The Esper engine has been developed to address the requirements of applications that analyze and react to events.

PDF:
Complex Event Processing with Esper
JAX India 2008, Papick G. Taboada

Short talk at the Jax 2008: Android

P.G.Taboada — Wed, 02 Apr 2008 08:27:51 +0000

Steffen and I will be talking at the mobility day about Google’s mobile platform Android:

Google Android: Uncanny Valley – unheimliches Tal? Google Mobile für Java Entwickler

Im November 2007 stellt Google ein Handybetriebssystem namens Android vor. Das entsprechende SDK für Android-Applikationen ist Java-basiert, kommt mit Eclipse Plug-in, hat Bibliotheken für openGL, Bluetooth oder USB und produziert Java Byte Code. Ausgeführt wird dieser allerdings nicht auf einer JavaVM. Der Vortrag zeigt die Möglichkeiten des neuen Ansatzes in einer Welt fern von JCP-Standards.

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…

Non invasive GWT and Spring integration

P.G.Taboada — Thu, 14 Feb 2008 08:44:20 +0000

[update]
If you are working with GWT 1.6, you probably would like to have a look at this here:
http://pgt.de/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/
[update]

Obviously I am not the only one looking for a way to integrate my Spring backend into some GWiT application. After searching for a while I didn’t find any suiting solution. There are some interesting approaches (like GWT Widget Library SL and using the maven plugin), but being new to GWiT I did not want to give up the GWiT Development Shell neither the embeded Tomcat. I wanted the integration to be less invasive as possible.

So here is what I did…

First problem I had to solve was how to get my configuration elements into the tomcat configuration. I needed to add some listeners to the web.xml (e.g. to start the Spring container and Acegi security):

Here is a snippet from my web.xml showing how to use the listeners provided by the Spring Framework to start an application context and to configure log4j properly:

(...)
...)
 
log4jConfigLocation
/WEB-INF/log4j.xml
 
contextConfigLocation
classpath:/META-INF/spring-conf.xml
 
			org.springframework.web.util.Log4jConfigListener
 
			org.springframework.web.context.ContextLoaderListener
 
			org.springframework.web.context.request.RequestContextListener
 
(...)

GWiT does not provide any extension point for custom configuration, so I had to add the configuration elements directly to the provided Tomcat web.xml. I cannot make changes to the web.xml in the ROOT web application, since this web.xml is re-generated by GWiT every time the Development Shell is started. Fortunately, the default web.xml stored in the “conf” directory of the embedded Tomcat is generated only one. So I found some place to add my configuration elements. Unfortunately the configuration there is not reusable, so I am having double configuration here: configuration for the development and configuration for the deployment.

Next, I wanted to easily have access to my Spring beans. JSF developers have a variable resolver and have access to their Spring beans for free. I wanted that too. Again, being new to GWiT, I didn’t want to loose the features provided by the IDE (Eclipse + GWT-Designer in this case). It is nice to simply say “add new remote service” in the IDE and get everything wired out of the box. For different reasons I do want to expose my Spring beans automatically to the GWiT application. JSF developers have the services for free at the SERVER SIDE: the services do not get exposed via RPC automatically. I wanted something similar: my GWiT remote service implementation should have access to the Spring backend for free without exposing anything automatically.

I wanted some sort of dependency injection. Since the servlets are managed by the servlet container and the servlet container does not know anything about dependeny injection of Spring beans into servlets I had to do it myself.

First, I needed some sort of markup to identify what to inject. I was using JDK 5 syntax on none client sources, so I used an annotation. I could also have used some marker interface for my services, but I found this to be to invasive, I did not touch my backend files.

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
 
/**
 * Annotation used to flag auto injection.
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(value = ElementType.METHOD)
public @interface AutoInject {
 
}

All I wanted to do is to add this annotation to my setter methods in my GWiT remote service implementations. So I extended the RemoteServiceServlet provided by GWiT and implemented the auto injection.

import java.lang.reflect.Method;
 
import javax.servlet.ServletException;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
 
import com.google.gwt.user.server.rpc.RemoteServiceServlet;
 
/**
 * Provides automatic injection into GWT services. Only setter methods with exactly one parameter and
 * annotated with AutoInject will be considered for auto injection.
 *
 */
public abstract class AutoInjectingRemoteServiceServlet extends RemoteServiceServlet {
 
    /**
     * Logger.
     */
    private static final Logger LOG = LoggerFactory.getLogger(AutoInjectingRemoteServiceServlet.class);
 
    /** Reference for the WebApplicationContext. */
    private WebApplicationContext ctx;
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void init() throws ServletException {
        LOG.debug("Initializing servlet");
        super.init();
        LOG.debug("Get reference to the Spring Application Context");
        ctx = WebApplicationContextUtils.getWebApplicationContext(this.getServletContext());
        System.out.println(ctx);
        LOG.debug("Spring ctx with: {} beans.", ctx.getBeanDefinitionCount());
        this.populateVariables();
    }
 
    /**
     * Performs auto injection on this servlet instance.
     */
    @SuppressWarnings("unchecked")
    private void populateVariables() {
        LOG.debug("Start servlet auto injection");
        Method[] methods = this.getClass().getMethods();
        for (int i = 0; i &lt; methods.length; i++) {
            Method method = methods[i];
 
            if (method.getName().startsWith("set") &amp;&amp; method.isAnnotationPresent(AutoInject.class)
                    &amp;&amp; method.getParameterTypes().length == 1) {
                Class type = method.getParameterTypes()[0];
                LOG.debug("Looking for: {}", type);
                String[] beanNamesForType = ctx.getBeanNamesForType(type, false, true);
                LOG.debug("Got {} with {} elements", beanNamesForType, beanNamesForType.length);
                if (beanNamesForType.length != 1) {
                    LOG.error("There is no bean of type {} for autoinjection", type.toString());
                } else {
                    try {
                        method.invoke(this, ctx.getBean(beanNamesForType[0]));
                        LOG.info("Injected bean: {} on field {} ", beanNamesForType[0], this.getClass().getName());
                    } catch (Throwable e) {
                        LOG.error("Error: could not inject into " + "protected variable {}, cause: {}", method.getName(), e
                                .getMessage());
                        if (LOG.isDebugEnabled()) {
                            e.printStackTrace();
                        }
                    }
                }
            }
        }
    }
}

In short: in the initialization of the servlet I pickup the Spring application context and do the injection for all setter methods annotated.

In the following GWiT remote service implementation I use this injection to get access to my Spring login service (that itself uses acegi, the user DAO and a session scoped bean):

public class GwtLoginServiceImpl extends AutoInjectingRemoteServiceServlet implements GwtLoginService {
 
	private ILoginService loginService;
 
	@AutoInject
	public void setLogService(ILoginService loginService) {
		this.loginService = loginService;
	}
 
	@Override
	public LoginResult doLogin(String username, String password) {
		LoginResult result = new LoginResult();
		try {
			result.loggedInUser = loginService.doLogin(username, password);
			result.successFull = true;
		} catch (BadCredentialsException bce) {
			result.successFull = false;
			result.errorMessage = "Bad credentials.";
		} catch (Throwable t) {
			result.successFull = false;
			result.errorMessage = "Server error.";
		}
		return result;
	}
 
	@Override
	public UserDTO isLoggedIn() {
		return loginService.isLoggedIn();
	}
 
	@Override
	public void doLogout() {
		loginService.doLogout();
	}
}

While this leads to a lot of delegation code, I am still happy with the layer separation and the easy usage.

When playing with GWiT 1.5 (build from the trunk) a few weeks ago, I noticed that GWiT started overriding the web.xml in the embeded Tomcat configuration directory. I just thought “oh no!”, but next thing I noticed was that it stopped overriding the application web.xml in the ROOT webapps folder. Let’s see if it stays this way…