GWT deferred binding tutorial

I just found a very good tutorial for the undocumented deferred binding featureof GWT. In this example the deferred binding is used to create a databinding framework for GWT.

While introducing deferred binding, it shows a very interesting data binding idea for GWT. Instead of solving the binding to the UI elements at runtime, this approach solves the problem during the compilation. This saves ressources at the client and even simplifies the development.

oop: java 7 session

Angelika Langer and Klaus Kreft held a session about the new features of the upcoming JDK 7. The presented roadmap shows JDK 7 (codename Dolphin) being released somewhere in the end of 2008.

First huge topic was the closures controversy. There is BGGA pushed by Neal Gafter, and there is Josh Bloch oposing with very good arguments. Both now Google. Interesting.

Closures is coming, there is no JSR yet, time will tell.

Another very interesting topic in the session was the superpackage features planned:

JSR 294: Improved Modularity Support in the JavaTM Programming Language

With superpackages it will be possible to define group of java packages, telling which ones are private to the superpackage and which ones are public. This allows us to create coarse grained modules and efficiently hide internal implementation. This is IMHO the most interesting Java extension in the jsr horizon.

While the JSR 294 introduces static modularization, there is still the need for runtime (and therefore deployment) modularization.

JSR 277: JavaTM Module System

The JSR 277 introduces modules and is similar to what we know from OSGi. Quite interesting to see all the module configuration elements as Annotations in the Java code. There is a nice blog posting about the modularization works from Glyn Normington (expert group members in the related JSRs, works for SpringSource).

The modularization planned for JDK7 is going to change the way we create components, as it provides the missing language features needed to create coarse grained components:

  • versioning,
  • side-by-side deployment,
  • repositories,
  • module bootstrap and
  • module lifecycle

I am curious to see how deployment will change in the future, and the future of Java EE in general. For example, Spring architectures lack deployment standards, now the standards are being provided by the Java SE.

And finally, but least interesting, some JSRs that probably will find their way into Dolphin:

JSR 310: Date and Time API

JSR 275: Units Specification

JSR 203: More New I/O APIs for the JavaTM Platform (”NIO.2?)

JSR 107: JCACHE – Java Temporary Caching API

JSR 296: Swing Application Framework

JSR 255: JavaTM Management Extensions (JMXTM) Specification, version 2.0

JSR 284: Resource Consumption Management API

Using Acegi to secure a GWT application

I am on the train to Munique on my way to the OOP 2008. Today I spent some time refactoring a GWT application (we are moving to GWT 1.5 built from the svn trunk) and thought I could use the travel time to post about GWT and Acegi.

GWT changes the way we develop internet applications. The web application is not only rich, but it also runs standalone in the client browser. Shortly spoken, a GWT application is a statically loaded set of html, css and javascript files. No serverside web technology gets touched in this process. The webserver delivering the files does not count here… Once the application starts running on the browser, it will start loading data from the server using http requests. This data will further on be displayed in the browser by the GWT application. An application delivered in Javascript is a security nightmare, since the code on the client side is readable and can be easily manipulated.

There are mainly two aspects in a GWT application scenario that might be secured:

– the GWT application
– the RPC services offered by the server

Securing the GWT application is an impossible task. It is possibe to only give access to the Javascript application after the user has identified itself, but once the Javascript code gets transfered to the client there is nothing that can be done to avoid manipulation.

Securing the RPC services offerend by the server is by far much more easier. Assuming the server is written in Java, there are many ways to secure the services offered: services in the GWT are RPC are implemented by Servlets. Restricting access to the servlets would do the job quite efficiently.

The approach described here does not try to hide the GWT application from the world. The application cannot be secured in the browser and, in many cases, it is the data and the serverside actions that must be secured. A GWT application that cannot connect to its RPC services because of bad credentials is useless. If the application algorithm is worth securing, then hiding the application is the best option available. Unfortunately, this cannot be done with GWT, it would be like a dog trying to bite it’s own tail. After all, the user must identify itself before, and then the application can be dowloaded to the browser. GWT does not known anything about lazy loading parts of an application at runtime. A simple way to implement hiding the application is to host the application in a JSP page ahd have this page secured. Not only the JSP must be secured, but also all static files composing the GWT application. Only after authentication succeeds, the JSP page can be accessed, bootstraping the Javascript application. The JSP should create a server session with the provided credentials, the GWT application would use RPC to gain access to this information and to know who has logged in. This is a server side approach, and here is where I tend to use Acegi.

Acegi is a very interesting Java security framework. It is often used with Spring and with web applications, but it also can be used standalone (without Spring) and to secure any kind of Java application. With AOP techniques its usage can be non invasive to the application code.

In our project we did not hide the GWT application. First, it is an intranet application. Second, the application is useless without the RPC services and the provided data.

The idea on our approach is to download the GWT application to the browser and let the application display a modal login dialog box. The information provided by the user will then be sent to a unsecured login service on the server. The server performs the authentication through acegi, creates a server side session with the appropriate credentials.

Een if some user hacks the Javascript to bypass the login dialog, nothing will happen. The navigation tree is populated by RPC: each user has a different navigation tree, depending on user preferences, stored searches and security roles.

The login RPC call returns the login information required by the GWT application to know that a successful or unsuccessful login has occured. On a successful login, the GWT application starts loading the data needed through the secured services in the server. The server allows this services to be called because the client has created a valid server side session with apropriate credentials. Acegi will secures the services based on this information.

Finally, our GWT application checks regularly if the session has not been invalidated (or if the server is respoding at all) and performs a client-side logout if needed.

Feedback is welcome!

It is not a library!

I recently worked on an article about GWT where I showed two sides of GWT.

First, GWT defines a new way of developing Webapps. By redefining our procedure of development, providing the GWT-Compiler and the development shell and the GWT-Browser in the hosted modus, GWT allowes us to develop in Java, in our favorite IDE and use all the techniques we got used to in the last years: code completion, refactoring, debugging, code analysis, check styling, etc.

Second, GWT provides the ground framework to help us develop better web applications. There is the component model, the i18n, the browser history manipulation and many more. This is where it gets a little confusing. While other technologies get runtime dependencies exactly here to the product, GWT does not. It is a compile time dependency. We can’t switch a jar or a script file in the app and get new features at runtime. The application created with GWT is a kind of a binary, it must be recompiled. And this is good.

This was clearly pointed out in the Voices That Matter GWT conference.

There is a video called “Conference Wrap Up” on YouTube. Have a look at 25:00 timeframe.

Different rights for files and dirs

This is one snippet that I sometimes need, but always forget how it looks like:

  • to change directory rights:

find . -type d -exec chmod 740 „{}“ \;

  • to change file rights:

find . -type f -exec chmod 640 „{}“ \;

Obviously I do not need it often enough (or I would rembember it and this posting would not have happened), or I am a linux noob – I am not sure yet.

At least, now I know where to copy and paste from next time.