UrlBlogGrey

This presentation focused on NetBeans 5.5 as a tools-platform for Java EE 5. I really dislike presentations like this one because they draw in people interested in Java EE 5, but the presenters have the goal of advertising their tool or platform. If I wanted to be sold something, I would have gone to the Pavilion to hang out in the vendor booths and score some free stuff.

The only interesting part was hearing about what's going to be present in Java EE 5:

• regular POJOs with annotations instead of deployment descriptors


• incorporation of JAX-WS technology for web services


• dependency injection, a la Spring


• better default behavior & configuration (huh?)

I've got mixed feeling about annotations because they have the ability to pollute the source code with deployment information. And, if the deployment information changes in the generated descriptors, they become out-of-sync with the compiled code.

Posted by Scott at 9:21 AM | Permalink

AJAX borrows heavily from Dynamic HTML (DHTML), and was actually introduced in 2002 as part of Mozilla 1.0. AJAX is JavaScript using DHTML to dynamically render a web page with content obtained asynchronously from a remote server transparently to the user. This can be triggered by something like dragging the mouse, as in Google Maps.

The XMLHttpRequest (XHR) used in JavaScript functions is the backbone of AJAX. A quick demonstration showed why the XHR requests should be handled asynchronously using callback functions registered with the browser. Use of synchronous functions caused the browser thread to hang until a response was obtained by the server, which could result in a really bad user experience.

The presenters inisisted that applications like Google Maps are actually fairly simple UIs to build because of AJAX. They were actully able to come up with a clone of Google Maps in merely 3 hours.

There are a number of tools available for browsers like Firefox that use AJAX to improve the browsing experience. One such tool is GreaseMonkey, which allows users to inject AJAX content into any web page. For example, you could inject AJAX content into an Amazon page in order to view competitors prices or related information on the web.

Debugging DHTML can be extremely difficult since the content of the page can change at will. So, it's valuable to have tools like the DOM Inspector present in the Safari and Firefox web browsers. This will allow you view the HTML document graph in real-time, regardless of how the page looked when transmitted over-the-wire.

Posted by Scott at 9:01 AM | Permalink

This presentation focuses on the upcoming JetBrains product "Team Server".

Team Server seeks to make development teams more productive. It integrates with IntelliJ, web browsers, version control systems, and agents. Agents offer an extension of Team Server to provide additional build services (i.e. distributed builds, etc.).

The browser interfaces use AJAX to provide real-time status of the build. It looks a lot like CruiseControl, but with a much more polished interface, IntelliJ integration, and support for agents that can extend the Team Server capabilities.

The Agents feature is what differentiates Team Server from the competition. It introduces the concept of the Build Grid, which is already available in other build systems (i.e. Apple's XCode with GCC). Because there are usually more check-in than builds, the build grid offloads builds to separate agent nodes.

An interesting build-related feature is delayed check-in, which addresses the problem of the 5 o'clock check-in. When a developer commits their changes before learning the built results, it could negatively affect the productivity of local or remote team members. A delayed check-in states that the build system will delay check-in until it has verified that the build succeeds. No check-in will be done if the build fails.

Build notifications are often ignored by developers, not because of lack of concern, but because of their sheer volume. Suggestion is to e-mail only on failed builds, builds with my changes, or if no one is responsible for failure (i.e. scheduled weekly build).

Another neat feature is the ability to indicate ownership of a build failure by "taking responsibility." This indicates that the problem has been acknowledged and is being addressed. This capability is current missing in tools like CruiseControl.

Instant Messaging is coming to IntelliJ, too. It relies on the Jabber XMPP communication protocol, which is also used by NetBeans and other IDEs.

The speaker, Dmitry Jemerov, did an excellent job of presenting.

Posted by Scott at 8:58 AM | Permalink

Goal is to take an arbitrary Spring application and deploy it in a cluster without focusing on a clustered deployment.

Presented possible solutions using JMS or JCache to synchronize client sessions and data across multiple JVMs/Servlet containers. Argument is that the VM, or application server facilities, should coordinate cluster operations transparently to the application. Also, the serialization behavior in the Java language has traditionally required entire object graphs to be synchronized in a cluster whenever a single attribute in an object graph is changed. This is incredibly inefficient and should be avoided.

So, how does Spring help us solve clustering? Terracotta, using Spring, permits the injection of clustering facilities into clustered applications at runtime. It turns the Spring ApplicationContext events into distributed reliable events. Shares JMX states, and Spring Webflow's page flows. All of this is managed declaratively through the Terracotta XML configuration file.

This sounds really interesting, and the Spring ApplicationContext seems like an ideal point for synchronization. It's unfortunate that the presenter did such a poor job structuring the session (30 minutes on clustering solutions that don't work).

Posted by Scott at 8:57 AM | Permalink

JConsole is a valuable tool for obtaining information about interactive and non-interactive applications. MBeans are always present in the JVM - JMX and tools driven by JMX (i.e. JConsole) are just used to harness the information they provide.

MBeans hookup attributes, notifications, and operations. Mustang (Java 6) allows you to connect to any Java process on the local machine, regardless of whether it was started with JMX configuration options.

There is a challenge in connecting the JMX MBeans in the JVM and the runtime objects associated with your application. Example: adjusting a cache size at runtime using JMX. Here are the speaker's identified methods of establishing this connection.

Method 1: Information Grabbing
MBean consults global fields or methods. This is the simplest technique, but violates modularity. If the MBean can see the object it needs, then so can anyone else.

Method 2: Information Shoving
In this case, the cache object registers itself with the JMX server when initialized. The downside is that the cache class becomes "polluted" with JMX-aware code. An additional downside is that registering an MBean of an instance in the class' constructor can lead to race conditions.

Method 3: Quantum Entanglement
Lots of MBeans can become "entangled" whrough their registration mechanisms. This is bad.

Method 4: Dependency Injection
Borrowed from other technologies like the Spring Framework. An XML or similar configuration file can be used to inject the cache object dependency into the MBean. Spring can be used to accomplish this. So can Java 6 (Mustang), which supports dependency injection via annotations.

Method 5: Aspect-Oriented Programming (AOP)
An aspect can be used to link the MBean and cache class instance. This, too, can be accomplished using the AOP capabilities of Spring. The class is modified or augmented from the "outside" to leverage JMX.

All of the solutions featured in the presentation can be run using Mustang, which is available now.

It's important to return snapshot values in container Java Bean objects since it ensures consistency among the container's data elements. It possible that the container's attributes could become discoupled if accessed independently.

A problem that's being addressed by MXBeans is that the container class must be known in advance by the JMX client accessing a container instance. MXBeans were designed for the instrumentation of the VM itself (JSR 174).

JMX Web Services Connector is being defined by JSR 26. Allows clients of JMX agents on non-Java platforms to monitor a Java application while exploting the web platform. It supports SOAP 1.1 over HTTP. It works with non-JMX clients by publishing a WSDL at a known location. It relies on basic authentication and SSL.

An AJAX/JSR 262 demonstration was given that represents a non-Java client running with a JAX stack. It showed how an MBean agent can be accessed using XML Web Services, and the content provided by JMX is displayed and updated in a web browser using AJAX.

In Java 1.7 (?!?) Dolphin, there is a proposed feature that will allow cascading of MBeans through Master-Slave server relationships. This would allow a JMX client to access the master and have access to MBeans residing in slave servers.

Posted by Scott at 12:52 PM | Permalink

The General Session of JavaOne 2006 kicked-off with Johnathan Schwartz introducing several members from industry, including Marc Fleury from JBoss. Fleury recently had his company, that provides support services for the open-source JBoss Java EE application server, acquired by Redhat. I have an eternal grudge against Fleury because of his rude and offensive behavior at a small, birds-of-a-feather session during JavaOne 2003. His arrogance and preference for offensive language make him less of a leader, in my mind. In any case, Schwartz was thrilled to associate Sun with JBoss.

A demonstration was given on the AJAX capabilities of Java. The age-old Petstore application was re-worked to use AJAX. It featured some nice UI techniques to make the website more dynamic and visually-appealing. The website where the Petstore demo can be obtained from is here.

Posted by Scott at 12:50 PM | Permalink

EMC Documentum will be sending me to the annual JavaOne conference for the first day (Tuesday, May 16). While I attended all days of the conference in past years with SRA, it's still nice that EMC is sending some people. I heard that SRA isn't sending anyone from my previous contract. Anyhow, here's my schedule for Tuesday. I'm most interested in the following areas: Spring Framework, Java Management Extensions (JMX), and AJAX (a.k.a. Web 2.0). I'll be blogging my notes from sessions during the conference, so keep posted.

Posted by Scott at 11:27 AM | Permalink