Google Web Toolkit (GWT or "GwiT")- JBOSS WORLD 2009

A web performance enhancement toolkit that converts Java classes into runnable javascript code. This is done by using the GWT "compiler" which optimizes and minimizes the code deployed / reduces the payload overhead of images & content.

Tools:

• JavaScriptObject- any class extending this class will be used by GWT to look into the comments after the class "definition" (usually empty) to determine the javascript specific calls to use. Imagine php tags, but after java classes. That is what this boils down to. Embedding Javascript into Java. In theory the class is able to "compile" and "run", but in practice this looks flaky. There is a reason we moved to MVC and MVP, and minimized the ammount of 'comment managed code'.

• SOYC - "Story of your compile" - allows browsing of the GWT "compile" process. Feels more like a "compile debugger" - shows the process by which the Java classes turn into javascript pages. Extremely important, given the fact that "print(x+y)" will "compile" to "4" in the javascript if the only options of x+y are 2 & 2. This seems extremely efficient (why send x&y over the pipe, when 4 is good enough), but will make debugging a nightmare.

• ImageBundle - define a class as an extension of the imagebundle and annotate @Resources to be included with the bundle to aggregate all of them into one cached image group. Minimizes communication to the client & maximizes client cache hits.

neat elements:

• Can define class specific .css changes with @Define css-var css-val; at the appropriate scope.
• Can define class spericic & browser specific .css changes with @If browserA css-var css-val;

The performance benefits of GWT cant be stressed enough. Client load times showed reduction by 90% - and those client load times couldn't have been reduced in any other way. Troubleshooting looks like a very high learning curve. It seemed to me that typing was thrown out the window with GWT. Perhaps I am wrong. Unless I have to look at wicked optimization, GWT will remain outside of my toolkit.

JBOSS & Spring - JBOSS WORLD 2009

Jboss registers all spring application context instances which will allow management of the scope of individual beans, allowing for session or request based bean lifecycles. It also enables the sharing of beans between different WARs.


This can be managed by either a Jboss specific bean factory locator or via the JBOSS deployer.


Using the BeanFactoryLocator ends up being a list of bean factories contained within a static singleton lookup table.


The Jboss Deployer recognizes the spring.xml in your root WEB-INF directory, bootstrapping the application context & loading it into you JNDI registry.

This allows beans in other application contexts to access beans outside of their servlet space.

The application context is enabled in the servlet space by referencing either the VFSClassPathApplicationContext within the web.xml.

Shared JPA & JTA require a SharedEnitityManagerFactory wiring to be added in either the ApplicationContext or the JBOSS deployer.

Autowiring is still functional, but requires the JBOSS-Deployer if context/lifecycle management is required.

One of the biggest benefits touted was the ability for the application to utilize JBOSS's underlying ThreadPoolManager for Asyncronous calls via spring intialization.

Injection into SEAM managed projects is enabled.