But this time, the team posted several comments on whether GWT is dead or not (mainly because of the fuss around Dart), and Ray Cromwell posted a comment providing some insight on what is [...]]]> Normally the GWT team does not comment on future milestones, releases and does not provide an official roadmap (Issue 7013).

But this time, the team posted several comments on whether GWT is dead or not (mainly because of the fuss around Dart), and Ray Cromwell posted a comment providing some insight on what is coming on GWT 2.5:

The next release or two of GWT may include more core improvements than the last few point releases of GWT so far, consider:

1) Compiler optimizations that reduce code by size by 30% uncompressed, and 15% gzipped
2) SourceMap support and Source-Level Java debugging in Chrome (and hopefully Firefox)
3) A „super draft mode“ that can recompile many apps in under 10 seconds and most under 5
4) New „to the metal“ „modern browser“ HTML bindings
5) Testing framework that makes GUI testing delightful
6) Incremental compile support to speed up production compiles

So code will be getting smaller, faster, easier to debug (in some situations) and test, and compiles will go quicker. This reflects somewhat the shift in GWT team composition, but as people ramp up on other parts of the SDK (e.g. MVP stuff), I’m sure there will be improved responsiveness to fixing bugs in that area as well.

Add this to the list of issues already fixed and scheduled for 2.5, and we will have a really interesting release.

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

Many companies are still stuck in – IMHO – the most successfull vendor-version lock-in web history. Ever heard this?

I cannot upgrade IE in our company because of [...]]]> When you start developing complex enterprise applications using GWT, you can run into the problem that IE does not perform quite well with too much JavaScript.

Many companies are still stuck in – IMHO – the most successfull vendor-version lock-in web history. Ever heard this?

I cannot upgrade IE in our company because of  (…)*

(*) You can fill in you favorite corporate intranet application that won’t work elsewhere, only in IE6.

And even if you can upgrade IE to the latest version (actually IE8), it won’t get much better. Chrome, Opera, Firefox and Safari – pic anyone and you will see that the RIA in question can be fast.

And here is where Google comes to the rescue. In a recent blog posting, the Chromium declared that “chrome is ready for business“:

Both Chrome and Chromium are now manageable through Group Policy objects on Windows, plist/MCX configuration on Mac, and special JSON configuration files on Linux. We polished up the NTLM and Kerberos protocol support, and created a list of supported policies and administrative templates to help administrators deploy.

This is good news for companies willing to switch from IE to chrome, but for those sticking to IE we still have the nochrome-vendor-version lock-in. And this is the greatest problem: how do you switch to a modern browser, if you must run several applications in IE? The answer is simple: you switch the rendering engine inside IE, but not for all applications, just for those explicitly asking for it:

For users needing access to older web applications not yet qualified for Chrome, we also developed Chrome Frame, an Internet Explorer (TM) plug-in that provides Chrome-quality rendering for the broader Web, while defaulting to host rendering for any web applications that still require IE.

This way, IE will work as always, but if some page adds a simple html or http header, google chrome will do the rendering of the page, inside IE. Users don’t have to switch from one browser to another, and the IT department can rollout one web application upgrade after another, without compromising legacy apps.

You could even use a proxy with content adaptation to add the required http header to all pages from the internet.

I mean, really, even Microsoft says you should upgrade:

Microsoft’s urging to upgrade to IE8 appears to be partially in response to the German and French governments’ recommendation that people stop using Internet Explorer altogether due to its security vulnerabilities.

Microsoft’s announcement said: “It is important to note that all software has vulnerabilities and switching browsers in an attempt to protect against this one, highly publicized, but currently limited attack can inadvertently create some false sense of security. Moreover, IE8 has other built-in security protections, such as the SmartScreen filter, that other browsers do not have that protect against real consumer threats, such as socially engineered malware and phishing attacks.”

My first though is, what exactly is meant with “standard”? A short look at Wikipedia shows:

Open Standard: An open standard is a standard that is publicly available and has [...]]]> This is a sort of “standard” question when it comes down to the topic web frameworks, Java and finally the Google Web Toolkit (GWT).

My first though is, what exactly is meant with “standard”?

A short look at Wikipedia shows:

Open Standard: An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed (e.g. open process). There is no single definition and interpretations do vary with usage.

De facto standard: A de facto standard is a custom, convention, product, or system that has achieved a dominant position by public acceptance or market forces (such as early entrance to the market). De facto is a Latin phrase meaning “concerning the fact” or “in practice”.

Internet standard: In computer network engineering, an Internet Standard (STD) is a normative specification of a technology or methodology applicable to the Internet. Internet Standards are created and published by the Internet Engineering Task Force (IETF).

No, no,  no! Not that kind of standard, right? Ah, ok, the Java EE standard!

Again, looking at Wikipedia you will find the following under “nomenclature, standards and specification“:

Java EE is defined by its specification. As with other Java Community Process specifications, providers must meet certain conformance requirements in order to declare their products as Java EE compliant.

Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc., and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets, portlets (following the Java Portlet specification), JavaServer Pages and several web service technologies. This allows developers to create enterprise applications that are portable and scalable, and that integrate with legacy technologies.

Which leaves us just a few options: the Servlet/ JSP and the JavaServer Faces specifications. While the Servlet and JSP specifications focus on how to handle HTTP request/ responses, the JSF specification defines a GUI component model for web applications.

The problem here is: there is no room anymore for another “compliant” web framework – JSF made it into the Java EE specification – end of line. But, despite of a wide industry support, JSF is not the only web framework being used today by Java developers. And to make things a little more trickier, typical Web 2.0 web applications do not render the UI on the server side but in the browser.

Fancy “Web 2.0″ applications are not written in Java. Rich user interfaces are being rendered completely in the browser, avoiding the server roundtrip and minimizing latency. How? By simply using DHTML (technologies defined by the W3C).

So is this the end of Java? No! You will find people using Java backends for “Web 2.0″ applications. But even as a backend technology we won’t be abiding by the rules of standard compliance by using RMI or SOAP to communicate: it is common to send lightweight JSON over HTTP. All you need for that is a Servlet and a little bit of JSON <-> Java objects mapping. People developing RIAs and using JSON back and forward to the server are measuring latency in milliseconds.

So, if you will be building a Web 2.0 application, don’t look for a specification at the Java EE side. It is the wrong side, as Java is actually the backend, not the frontend. That brings us back to the first standards I cited above: open standards, de facto standards and internet standards.

This is how things were before JSF, and this is how things became after Web 2.o.

So, back to the question, is GWT standard compliant or not? Well, besides of those blue boxes on the picture above I would say yes!

• The compiler is not standard, but I would not know what a standard compiler would be or mean to development anyway
• The GWT-RPC mechanism is highly GWT proprietary, don’t use it if you don’t like it. But it is my belief that there aren’t too many developers out there that can code something better than GWT-RPC by hand…

The GWT generated files make it quite easy to follow some of the tips for building a cache-aware site:

If a resource (especially a downloadable file) changes, change its name. That way, you can make it [...]]]> GWT applications are basically a bunch of static resources, and static resources are strong candidates for browser caching.

The GWT generated files make it quite easy to follow some of the tips for building a cache-aware site:

If a resource (especially a downloadable file) changes, change its name. That way, you can make it expire far in the future, and still guarantee that the correct version is served; the page that links to it is the only one that will need a short expiry time.

If we have a look at the generated files we will find

• strongly unique filenames
• cache and nocache hints in the filename

It would be possible to add servlet filters to the Java EE Web Container (I will call it tomcat from now on…) delivering those files, but I prefer to have it outside of tomcat. As long as I don’t find the “GWT optimization all-in-one-filter” I will keep using the Apache http server for optimization. Besides, it is not unusual to hide one ore more tomcat instances behind an Apache http server.

Well, I found it quite tricky to setup compression, http headers and the right proxy configuration, so here is my config as of today…

I am using mod_deflate, mod_expires and mod_headers, mod_proxy and mod_proxy_ajp. It is up to you to have those loaded in your Apache configuration. Load balancing with mod_proxy_balancer is out of scope for this article.

So here is my configuration:
[update]
I added a version number to the configuration.
[/update]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#
#  Version 2
#  Source: http://pgt.de/2011/01/27/apache-configuration-for-gwt-applications/
#
<IfModule mod_proxy.c>
   <IfModule mod_proxy_ajp.c>
 
      <IfModule mod_expires.c>
         ExpiresActive On
      </IfModule>          
 
      <IfModule mod_headers.c>
         <ProxyMatch (.*)nocache\.js$>
            Header Set Cache-Control "max-age=0, no-store"
         </ProxyMatch>
         <ProxyMatch (.*)\.cache\.(.*)>
            Header Set Cache-Control "max-age=31536000, public, must-revalidate"
         </ProxyMatch>
         <ProxyMatch (.*)\.cache\.js$>
            Header Set Cache-Control "max-age=31536000, private"
         </ProxyMatch>
      </IfModule>          
 
      <IfModule mod_deflate.c>
         SetOutputFilter DEFLATE
         AddOutputFilterByType DEFLATE text/plain
         AddOutputFilterByType DEFLATE text/html 
         AddOutputFilterByType DEFLATE text/xml  
         AddOutputFilterByType DEFLATE text/css  
         AddOutputFilterByType DEFLATE text/javascript
         AddOutputFilterByType DEFLATE application/xml
         AddOutputFilterByType DEFLATE application/xhtml+xml
         AddOutputFilterByType DEFLATE application/rss+xml  
         AddOutputFilterByType DEFLATE application/javascript
         AddOutputFilterByType DEFLATE application/x-javascript
         AddOutputFilterByType DEFLATE application/x-shockwave-flash
      </IfModule>          
 
      <Proxy *>
         <IfModule mod_expires.c>
            ExpiresByType application/json   "now"
            ExpiresByType text/css            "now"
            ExpiresByType text/html          "now"
         </IfModule>
         <ifModule mod_headers.c>
             Header unset ETag
             Header unset Last-Modified
         </ifModule>
         FileETag None
      </Proxy>
 
      <Location /gwt>
         ProxyPass         ajp://localhost:8009/gwt
         Order allow,deny
         Allow from all  
      </Location> 
 
   </IfModule>          
</IfModule>

As you can see I turned off caching of css and html files for my GWT app for a simple reason: my GWT apps follow the single page principle, so users won’t leave/ reload the page. And when they do, it is ok to deliver the actual version. You can fill in your own strategy here, depending on your own application lifecycle.

The compression is working fine, as you can see at the difference between the size and the transfered size:

As configured, the expiration headers for the cacheable filenames are set to the far future, here are the headers for a split point:

And, as required to get updated GWT apps pushed to the clients on a browser refresh, the http header for the not cacheable file:

Building any large scale application has its hurdles, and GWT apps are no exception. Multiple developers working simultaneously on the same code base, while maintaining legacy features and [...]]]> There is a two part article on the GWT docs homepage talking about large scale application development and GWT. Sorry, this is a crosspost from here…

Building any large scale application has its hurdles, and GWT apps are no exception. Multiple developers working simultaneously on the same code base, while maintaining legacy features and functionality, can quickly turn into messy code. To help sort things out we introduce design patterns to create compartmentalized areas of responsibility within our project.

Part I

http://code.google.com/intl/de/webtoolkit/articles/mvp-architecture.html

Model view presenter, AppController, binding presenters and views, EventBus, history, testing

Part II

http://code.google.com/intl/de/webtoolkit/articles/mvp-architecture-2.html

Complex UIs, optimized UIs, and code splitting.

Google usually publishes the sessions on youtube and uploads the slides to the respective session homepage. Ray Ryan is talking on two session, one of it is called “Architecting GWT applications for production at Google” – maybe it [...]]]> Here are the GWT sessions on the upcoming google i/o 2010 to keep an eye on.

Google usually publishes the sessions on youtube and uploads the slides to the respective session homepage. Ray Ryan is talking on two session, one of it is called “Architecting GWT applications for production at Google” – maybe it is part two of his last talk on gwt architectures best practices.

I surely won’t miss any of those:

Architecting for performance with Google Web Toolkit

Modern web applications are quickly evolving to an architecture that has to account for the performance characteristics of the client, the server, and the global network connecting them. Should you render HTML on the server or build DOM structures with JS in the browser, or both? This session discusses this, as well as several other key architectural considerations to keep in mind when building your Next Big Thing.

GWT + HTML5 can do what?!

How can you take advantage of new HTML5 features in your GWT applications? In this session, we answer that question in the form of demos — lots and lots of demos. We’ll cover examples of how to use Canvas for advanced graphics, CSS3 features, Web Workers, and more within your GWT applications.

GWT’s UI overhaul: UiBinder, ClientBundle, and Layout Panels

There have been some really huge improvements in GWT’s UI fundamentals over the past year. We’ve introduced features such as UiBinder, ClientBundle, CssResource, and uber layout panels that allow you to build fast UIs in a sane manner. Come see how fun/easy/fast it can be to use these technologies in harmony to overhaul your UI.

GWT continuous build and testing best practices

GWT has a lot of little-publicized infrastructure that can help you build apps The Right Way: test-driven development, fast continuous builds, code coverage, comprehensive unit tests, and integration testing using Selenium or WebDriver. This session will survey GWT’s testing infrastructure, describe some best practices we’ve developed at Google, and help you avoid common pitfalls.

Architecting GWT applications for production at Google

For large GWT applications, there’s a lot you should think about early in the design of your project. GWT has a variety of technologies to help you, but putting it all together can be daunting. This session walks you through how teams at Google architect production-grade apps, from design to deployment, using GWT.

Measure in milliseconds redux: Meet Speed Tracer

It turns out that web apps can be slow for all sorts of opaque and unintuitive reasons. Don’t be fooled into thinking that bloated, slow JavaScript is the only culprit. This session introduces you to Speed Tracer, a new GWT tool that can tell you exactly where time is going within the browser.

Faster apps faster: Optimizing apps with the GWT Compiler

The GWT compiler isn’t just a Java to JavaScript transliterator. It performs many optimizations along the way. In this session, we’ll show you not only the optimizations performed, but how you can get more out of the compiler itself. Learn how to speed up compiles, use -draftCompile, compile for only one locale/browser permutation, and more.

GWT Linkers target HTML5 Web Workers, Chrome Extensions, and more

At its core GWT has a well-defined and customizable mechanism — called Linkers — that controls exactly how GWT’s compiled JavaScript should be packaged, served, and run. This session will describe how to create linkers and explains some of the linkers we’ve created, including a linker that turns a GWT module into an HTML5 Web Worker and one that generates an HTML App Cache manifest automatically.

Aus den “release notes“:

Speed Tracer on a Mac

I finally got Speed Tracer running on Mac OSX. Just in case you missed the news: GWT 2.0 was released yesterday and brought a nice friend called Speed Tracer.

The tool itself is written in GWT (funny, don’t?) and works as an Chrome extension. Since Chrome for [...]]]>

Speed Tracer on a Mac

I finally got Speed Tracer running on Mac OSX. Just in case you missed the news: GWT 2.0 was released yesterday and brought a nice friend called Speed Tracer.

The tool itself is written in GWT (funny, don’t?) and works as an Chrome extension. Since Chrome for Mac is beta and does not have support for extensions we nee to use use Chromium.

There are postings on how to get extensions running on Chrome for Mac, but I preferred to use a Chromium build.

Speed Tracer is a Google Chrome extension that helps you identify and fix performance problems in your web applications. It visualizes metrics that are taken from low level instrumentation points inside of the browser and analyzes them as your application runs. Using Speed Tracer you are able to get a better picture of where time is being spent in your application.

Thanks to pohl (irc chat on ##gwt) for the hints.

So here we go:

1) We need some Chrome build that has “extensions enabled”. I used this one here, but you might try any other newer one.

2) Install Speed Tracer.

3) Start Chromium with the required command line parameter.

This part is the only real tricky one if you are not a geek… ;-)
From the Terminal you can start Chromium manually by executing the following…

/Applications/Chromium.app/Contents/MacOS/Chromium --enable-extension-timeline-api

… or you simply rename the bin to something else and place a script that does the command line magic for you.
I renamed Chromium to Chromium-bin and created a Chromium named script file that contains:

#!/bin/bash
exec "${0%/*}/Chromium-bin" --enable-extension-timeline-api

Don’t forget to make the script file executable…

That’s it. Now you can visit some ajax-funny site (google wave, google maps, google mail, google docs, you name it) and test drive Speed Tracer.

Good luck!

There [...]]]> I just read an interesting blog articles about “is GWT the future of web development or not“. I find the titles quite funny, because I really don’t believe that it was no ones intention to forecast the future, so the real question is – is GWT a good approach for present web development?

There is actually too much fuss about static or dynamic language. The best language is still the language I know best. I feel quite at home with Java and Eclipse – I won’t be any more productive in any other language so soon. If you are telling me that one can do things faster with Grails & Co. you might have a point (I really don’t know), but then we are talking about (web) frameworks and not about the language. I have my roots in Perl programming and I know exactly why I like type safety, but this again is a very personal statement.

Personally speaking, leveraging Java Programmers means really a lot to me. It is not only Eclipse and Java. It is checkstyle, findbugs, unit testing, build infrastructure. I have appreciated reading the GOF patterns, I loved Effective Java and I still have to chuckle when I think of the bad smells in Refactoring (which I somehow know all by personal history). When I do code in Java I mostly do it by consciousness and not by copy and paste from some sites like in my early days in development. Is a matter of fact, I do have something to leverage and it really means something to me.

But wait, let’t just don’t forget that GWT does something really tricky. It is not imposing some Java GUI component model on Javascript. They never left sight of what can be done with Javascript and can’t. It is not like RAP that tries put the Eclipse workbench on the browser, they are just being HTML and Javascript. And this is good and bad. It is good because it is about generating efficient Javascript, and bad because HTML looks ugly without lots of makeup.

If you are looking for eye candy in web development, don’t wast your time with GWT. And if you start doing SmartClient or GXT just know that you are not really leveraging GWT, thats just using GWTs infrastructure but nothing more.

If you are looking for software engineering in web development, take a closer look at GWT.

And yes, the GWT compilation is brutal. That’s why we have the developer modus (formerly known as hosted modus) – it starts fast and I keep it running. Simply refreshing the browser gives me the refreshed code, refreshing the jetty server gives me the changes in the backend. With OOPHM (out of process hosted modus) GWT looses the tight coupling to the only one browser on each OS by doing hosted modus inside-out. Google for it or try it out on your machine, works very good here. And, btw, I do have good monitor, a good chair and a fast computer. I mean, this is my day-to-day job.

I don’t know if scripting is the future, but I know it is the present when we speak of web development. Browser do speak  javascript and this won’t change in the near future, I mean, it is even getting worse (or better, you name it) with HTML 5, where we will be able to do 2D and video and much more just in javascript.

And when it comes to javascript in the browser, I don’t see any better approach then GWT at the moment.

Maturity? GWT is rock stable. It is more a compiler and does not really give me much runtime dependencies. We now have AdWords and Google Wave to showcase how far we can come if we have the knowledge and the resources.

And no, there is no eye candy.

If you are going down the GWT road, please have a look at the GWT Architectural best practices. If you like Spring (as I do), please have a look on how to use your Spring backend with GWT-dispatch (command pattern based RPC approach for GWT).

[update]

Joel has commented on the ranting post and it is hard to find it on the very long list of comments. That’s why I want to quote it here:

It’s unfortunate to see another long rant based on the same misunderstandings that we’ve seen from the day we released GWT. Very briefly, here are the major issues I see:

1. I don’t like Java, because Java programmers write reams of unnecessary abstraction.
We largely agree on this point (speaking for myself, at least, not everyone at Google). J2EE is a monstrosity, as is whatever library led to RequestBuilderFactoryFactory. This has precisely squat to do with Java the language.

2. Translating Java to Javascript necessarily leads to bad code, because some things can’t be translated well.
This is, in some sense, true. I really wish Java had a first-class function/method object (C# delegates would be fine). I wish Enum weren’t so damned heavy (we’re working on that). But the things that aren’t present in Java, that would be useful when translating to Javascript, probably account for <5% of the code we generate. So it’s irritating but largely irrelevant.

3. Compilation times take too long.
I hate them too. So what? But if you’re not using hosted (development) mode 99% of the time, you’re either doing something wrong, or you fall into one of a few special cases (e.g., new mobile libraries) that we’re working to address. Development mode gives you basically the standard edit/refresh cycle you get with Javascript, except that the compiler, generators, and other tools all get a chance to do work and catch errors.
Also, if you think you can get away without some sort of compilation process for a large Javascript application, you’re unfortunately mistaken. Badly. You can’t just concatenate a few hundred thousand lines of Javascript, strip out the comments, and hope for the best. You’ll end up with a monstrosity of several megabytes, even for a medium-sized app.

4. The widgets suck.
Fair enough. Hell, I wrote half of them, and don’t entirely disagree. Go write some that don’t. Oh, and when you run off to talk about how much Ext sucks, realize that you’re saying that Ext-JS sucks as well. Neither is the fastest library in the world, but they are very complete and cover a huge variety of use-cases. They made a very different set of tradeoffs than we did, but they’re a legitimate set of tradeoffs, and appeal greatly to enterprise developers that need to get a lot of UI built quickly.

5. Not all applications are Gmail.
No kidding. If I were a real pedant, I would point out that this is a tautology. But yes — if you’re building a simple “page at a time” app and need to add a little script to it, by all means use JQuery or whatever you feel like. That’s appropriate. Use the right tool for the job.

GWT was built to solve a specific set of problems, and we took what we believe are the right set of decisions to do so. Plenty remains to be done, and we continue to work on it. I wrote up a clarification on several of these points some time ago:
http://blog.j15r.com/2009/07/note-i-originally-posted-this-last.html
I hope this proves helpful to some.

Architekturkonzepte für GWT Anwendungen

Dieses Jahr finden noch [...]]]> In Zusammenarbeit mit der Firma OIO wurde die GWT Schulung angepasst. Jetzt werden auch die Architektur Best Practices aus dem Adwords Team besprochen:

Architekturkonzepte für GWT Anwendungen

• Serverseitige Integration mit dem Command-Pattern (gwt-dispatch)
• Clientseitige Dependency-Injection (google-gin)
• Umsetzung des Model-View-Presenter Entwurfsmusters (gwt-presenter)
• Loose Kopplung in der Anwendung durch Verwendung eines EventBusses

Dieses Jahr finden noch zwei Schulungen statt:

• Orientation in Objects, Mannheim, am 15.10. – 16.10.2009
• Orientation in Objects, Mannheim, am 03.12. – 04.12.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 [...]]]>
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.

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.

Works [...]]]> 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.

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App

A common question people ask is how to architect a GWT app. Ray Ryan discusses real-world learnings and patterns from the Google AdWords team and [...]]]> Just in case you haven’t seen it yet: there is very interesting talk from Ray Ryan available online:

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App

A common question people ask is how to architect a GWT app. Ray Ryan discusses real-world learnings and patterns from the Google AdWords team and elsewhere which you can use in your apps.

While dependency injection on the client side in general is nothing new, having it on a GWT application (I mean on the client) is something a little harder to setup. Since we don’t have reflection and dynamic proxies… But GWT provides an alternative called deferred binding, and there is a project called Gin providing the Guice DI approach for GWT apps.

There are some other projects like gwt-dispatch and gwt-presenter that where created inspired by Ray Ryans talk.

So if you are doing or planning GWT development, have a look at the video and the following projects:

• gwt-dispatch: Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, this is an implementation of the ‘command pattern’ discussed at the beginning of the video.
• gwt-presenter: Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, this is an implementation of the ‘Presenter’ part of the Model-View-Presenter (MVP) design pattern discussed in the video.
• google-gin: GIN (GWT INjection) brings automatic dependency injection to Google Web Toolkit client-side code. GIN is built on top of Guice and uses (a subset of) Guice’s binding language. By using GWT’s compile-time Generator support, GIN has little-to-no runtime overhead compared to manual DI.

If you are looking for an easy approach to use Spring in the backend with the gwt-dispatch project have a look at this posting:

• Use Spring with GWT dispatch

If you are looking for a simple and concise approach to use autowire your Gwt-RPC servlets with components from the Spring application context, have a look at this posting:

• Non invasive GWT and Spring integration (reloaded)

[update]

• mvp4g: all-in-one approach providing annotation based Event Bus, Dependency Injection, Model View Presenter, Place Service

[/update]

Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, “gwt dispatch” is an implementation of the ‘command pattern’ discussed at the beginning of the video.

The project uses Gin in the frontend and Guice in the backend. Guice defines a very [...]]]> From the GWT dispatch site:

Inspired by Ray Ryan’s Best Practices For Architecting Your GWT App session at Google I/O 2009, “gwt dispatch” is an implementation of the ‘command pattern’ discussed at the beginning of the video.

The project uses Gin in the frontend and Guice in the backend. Guice defines a very nice dependency injection framework, and as such, competes partially with the Springframework. But the Springframework is by far more than dependency injection, and I don’t want to miss any of its features in the backend.

So I took a look at the gwt dispatch sources, and decided to use Spring to setup the server side of the dispatch service. GWT dispatch extensively uses constructor injection. This works perfectly with Spring, but not with plain servlets. So I needed to rewrite the DispatchServiceServlet a little…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class StandardDispatchServiceServlet extends RemoteServiceServlet
		implements DispatchService {
 
	private Dispatch dispatch;
 
	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		WebApplicationContext ctx = WebApplicationContextUtils
				.getRequiredWebApplicationContext(config.getServletContext());
		AutowireCapableBeanFactory beanFactory = ctx
				.getAutowireCapableBeanFactory();
		beanFactory.autowireBean(this);
	}
 
	public Result execute(Action<?> action) throws ActionException {
		try {
			return dispatch.execute(action);
		} catch (RuntimeException e) {
			log("Exception while executing " + action.getClass().getName()
					+ ": " + e.getMessage(), e);
			throw e;
		}
	}
 
	@Autowired
	@Required
	public void setDispatch(Dispatch dispatch) {
		this.dispatch = dispatch;
	}
}

Instead of using constructor injection, I use setter injection. This way the servlet can be simply added to the web.xml. The servlet lifecycle initializes servlets before they are service-ready. I use the initialization callback method to autowire the servlet instance.

Here is my web.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<web-app>
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring-conf.xml</param-value>
	</context-param>
	<context-param>
		<param-name>log4jConfigLocation</param-name>
		<param-value>/WEB-INF/log4j.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
	</listener>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
 
	<!-- Servlets -->
	<servlet>
		<servlet-name>dispatchServlet</servlet-name>
		<servlet-class>x.y.gwt.hellospringdispatch.server.support.StandardDispatchServiceServlet</servlet-class>
	</servlet>
 
	<servlet-mapping>
		<servlet-name>dispatchServlet</servlet-name>
		<url-pattern>/hellospringdispatch/dispatch</url-pattern>
	</servlet-mapping>
 
	<!-- Default page to serve -->
	<welcome-file-list>
		<welcome-file>HelloSpringDispatch.html</welcome-file>
	</welcome-file-list>
 
</web-app>

I am using annotation based configuration in my project, so the spring configuration file is very concise:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?xml version="1.0" encoding="UTF-8"?>
<beans 
    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
    "
	>
 
	<context:annotation-config />
	<context:component-scan base-package="x.y.gwt.hellospringdispatch.server" />
 
</beans>

The component scan will add any properly annotated class to the spring application context. Obviously, the classes in the GWT dispatch project are not properly annotated. So I created the classes in my projects that are needed by the DispatchService implementation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import net.customware.gwt.dispatch.server.ActionHandlerRegistry;
import net.customware.gwt.dispatch.server.DefaultDispatch;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
 
@Component
public class DispatchBean extends DefaultDispatch {
 
	@Autowired
	public DispatchBean(ActionHandlerRegistry handlerRegistry) {
		super(handlerRegistry);
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import java.util.List;
 
import net.customware.gwt.dispatch.server.ActionHandler;
import net.customware.gwt.dispatch.server.DefaultActionHandlerRegistry;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
 
@Component
public class ActionHandlerRegistryBean extends DefaultActionHandlerRegistry {
 
	@Autowired
	public void setHandlers(List<ActionHandler<?, ?>> handlers) {
		for (ActionHandler<?, ?> actionHandler : handlers) {
			addHandler(actionHandler);
		}
	}
}

The action handler registry is the place where the ActionHandlers are kept. I used the collection autowire feature to get a list of all handlers registered in the Spring application context.

The last step is to add ActionHandlers to the Spring context. For obvious reasons I prefer to keep my action handlers “Spring free” – that’s why I created my own annotation to identify action handlers:

1
2
3
4
5
6
7
8
9
10

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
 
import org.springframework.stereotype.Component;
 
@Component
@Retention(RetentionPolicy.RUNTIME)
public @interface ActionHandlerBean {
 
}

I am not sure if I need to setup the retention policy – I should have a look at that…

All I need to do now is to add handlers to any package below the server package. The Spring component scan will automatically find the handlers and add them to the Spring application context and further inject them to the handler registry.

Here is a simple ActionHandler:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import net.customware.gwt.dispatch.server.ActionHandler;
import net.customware.gwt.dispatch.server.ExecutionContext;
import net.customware.gwt.dispatch.shared.ActionException;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Required;
 
import x.y.gwt.hellospringdispatch.server.support.ActionHandlerBean;
import x.y.gwt.hellospringdispatch.shared.SendGreeting;
import x.y.gwt.hellospringdispatch.shared.SendGreetingResult;
 
@ActionHandlerBean
public class SendGreetingHandler implements
		ActionHandler<SendGreeting, SendGreetingResult> {
 
	public SendGreetingHandler() {
	}
 
	public SendGreetingResult execute(final SendGreeting action,
			final ExecutionContext context) throws ActionException {
		final String name = action.getName();
		try {
			return new SendGreetingResult(name, "Hello from the server");
		} catch (Exception cause) {
			throw new ActionException(cause);
		}
	}
 
	public void rollback(final SendGreeting action,
			final SendGreetingResult result, final ExecutionContext context)
			throws ActionException {
		// Nothing to do here
	}
 
	public Class<SendGreeting> getActionType() {
		return SendGreeting.class;
	}
 
//	
//	@Autowired
//	@Required
//	public void setCustomerService(CustomerService gibher) {
//
//	}
//
 
}

I am very happy with this approach as it allows me to add new action (command) handlers without any configuration overhead. Simply dropping the implementation somewhere in the server package will do all the magic.

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 [...]]]>

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
 
<web-app>
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring-conf.xml</param-value>
	</context-param>
	<context-param>
		<param-name>log4jConfigLocation</param-name>
		<param-value>/WEB-INF/log4j.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
	</listener>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<!-- Servlets... -->
 
	<!-- Default page to serve.. -->
 
 
</web-app>

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
<beans 
    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
    "
	>
 
	<context:annotation-config />
	<context:component-scan base-package="x.y.gwt.hellospring.server" />
 
	<bean id="basicTextEncryptor" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
		<property name="algorithm" value="PBEWithMD5AndDES" />
		<property name="keyObtentionIterations" value="1000" />
		<property name="password" value="s0990w8eh0c8hf08aefh8hGf9egf9aefea8f" />
	</bean>
 
</beans>

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/**
 * 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:

1
2
3
4
5
6
7
8
9
10
11
12
13

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/. ]]> http://pgt.de/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/feed/ 14 http://pgt.de/2009/07/16/gwt-eclipse-i18n-and-utf-8-properties/ http://pgt.de/2009/07/16/gwt-eclipse-i18n-and-utf-8-properties/#comments Thu, 16 Jul 2009 05:37:27 +0000 P.G.Taboada http://pgt.de/?p=427 GWT does a great job reading UTF-8 encoded property files:

Both Constants and Messages use traditional Java properties files, with one notable difference: properties files used with GWT should be encoded as UTF-8 and may contain Unicode characters directly, avoiding the need for native2ascii.

This is nice, but there is a tiny little problem [...]]]> GWT does a great job reading UTF-8 encoded property files:

Both Constants and Messages use traditional Java properties files, with one notable difference: properties files used with GWT should be encoded as UTF-8 and may contain Unicode characters directly, avoiding the need for native2ascii.

This is nice, but there is a tiny little problem when using eclipse: the default encoding for java property files is ISO-8859-1.

This setting can be changed in the eclipse preferences:

Or you can change the encoding of a single file with “EDIT -> Set Encoding”…

So no more betas? Would be great to have a release in near future. People are expecting GWT 1.5 to be announced at the Google IO conference this week. Lets hope so!