IE: stack overflow at line: 0

Today, I noticed the following issue (IE only, of course). Running a page that does some comet (via “XHR GET” for long-polling), I got the following warning: “stack overflow at line: 0″  and the application stopped working…

I did some google-searches and found some “hints” that said I should disable my third-party tools for IE etc. That sounds strange…

In fact the problem was the odd cache behavior of the IE. The XML (from the “long-polling servlet”) was cached and its JS was executed; also the application itself started the polling too, so I (no IE) ran into this odd issue…

Changing the server-side code – that is responsible to render the XML – to have no cache rules (e.g.”Cache-Control”:”no-cache”) did the trick. It worked again. Of course, on your “comet output” you potentially don’t want cache to be present…

So fixing the cache solved the issue. There was no need to disable Norton or any other third-party tool…

What the Bayeux ? No portable (java) code !

Server-side-push (or comet) is gaining interest these days. Therefore, no wonder that the Bayeux specification/protocol is also gaining interest. The primary purpose of Bayeux is to implement responsive user interactions for web clients using Ajax and the server-push technique called Comet. The Bayeux spec is developed by the Dojo Foundation and contains a protocol definition. There is also a Java- and JavaScript-API offered by the Dojo Foundation. The API should be use by consumers when they build server-side soltuions (in YOUR project), extensions or even a Bayeux-based product.

Let’s take a closer look at the Java-API…

The “standardized” API from Dojo is located in their SVN. The (default) implementation of this API is part of the Jetty Container. So far so good… Now, when one decides to use Bayeux in a product, it would be (in theory) as simple as just using the API and getting started! Like you know from standards that are developed by the JCP, e.g. Java-Servlets…

However, there is a problem, today with that… There are several implementations of the Bayeux standard/specification, like:

• Apache Tomcat
• Jetty – the default/reference implementation
• Grizzly
• Weblogic (HTTP Publish-Subscribe Server)
• Netty from JBoss (soon)

This is not uncommon in the Java land. For instance, there are several EJB- or Servlet-containers out there. Choice is good! However… the JCP standard, like EJB or Servlet, forces the implementor of the specification to ship (or implement) an unified API, with single and unique namespace like javax.**. In the Servlet-API it looks like javax.servlet.**…

Not so in Bayeux… Almost every Bayeux-implementation comes with a different set of its public API. Huh ? This makes the development of real products – that have to run (and scale) on different application servers – impossible. In order to provide a portable solution you have to know the details of the actual API from the container you want to support.

Tomcat vs Jetty vs …

Let’s take a look at Tomcat and Jetty. Here is the same API, the Bayeux Message, but it is different in detail:

• Jetty’s Message interface
• Apache Tomcat’s Message interface

The above Message represents an object that is published to a channel, to be consumed by any other client (the spec explains the terms…).  Basically the above message interfaces try to implement the same contract, but the implementations are all very different and therefore incompatible:

• different package
• slightly different in terms the they have different methods defined.
• etc

So again, if one want’s to provide a Bayeux extension for all containers, he has to know some detail about the API of the “supported” containers. Sounds like you are really tied to a specific container OR you have to do lot’s of extra work…

Of course there is hope, that the vendors agree on a real, unified standard API. Like we know from those APIs that are defined by the JCP. Another interesting option is also the Atmosphere framework. It provides (another) proprietary API to make portable comet/server-side-push solution easy and possible. Under the hoods it hides all the oddness to support multiple different container-specific APIs. Not too bad!

What about the client-side code ?

Yes, Bayeux also has some client-side API. Basically when you use the jQuery plugin or the stuff that comes directly from dojo, you can use any server, since the message-exchange between browser and server is well-defined (in the protocol). So, if you create fancy Web-User-Interfaces you pick usually one library jQuery OR dojo. Or… you create your own client Bayeux API… Your product just ships the picked JavaScript library and you are fine. However replacing jQuery’s Bayeux support with the one from dojo also needs some extra work… but the entire front-end is still portable to other containers… which is not true for the server-side extensions, as said before…

Servlet 3.0

In Servlet 3.0 there will be a standardized API for doing asynchronous request processing. That means frameworks like Atmosphere aren’t needed on any Servlet 3.0 container, since there is:

• a common, public API (as part of the Servlet-API)
• the nasty implementation details are simply hidden by the container

Bayeux and Servlet 3.0

With the advent of an Servlet 3.0-based Bayeux implementation, there is hope! Such a solution is actually portable, since the API-implementation will use Servlet 3.0 instead of container-specific APIs. However still one problem is left, the different public APIs from all the available Bayeux implementations (as said before on the Tomcat vs Jetty section)… But with Servlet 3.0 the pain is not that big… You have to decide which Bayeux implementation you want to use and stick it into your product… Since the implementation of the chosen API will run on any container, IF it ONLY has Servlet 3.0 specific code (and NO use of container-specific APIs).

Jetty is coming..

The Jetty container, version 8, there will be a such a portable Bayeux implementation. Good news, and some hope for the near future!

Doing Enums in JavaScrip

Enums where added to Java in its version 1.5 and it is straightforward to use the:

public enum ChannelStates
{
  CONNECTED,
  CONNECTING,
  DISCONNECTED,
  RECONNECTING
}

Since JavaScript is becoming more and more important, at least when you are building a pretty rich ui framework, like ADF Faces,  you may run into the situation where you want the same in JavaScript. It isn’t really that hard at all. Take a look at the following JS/JSON object:

ChannelStates = {
  CONNECTED : 0,
  CONNECTING : 1,
  DISCONNECTED : 2,
  RECONNECTING : 3
};

That’s all you need. However, usually, you want this object, or “enum”, to be available as a global JS object, e.g:

...
ConnectionChannel.ChannelStates = {
  CONNECTED : 0,
  CONNECTING : 1,
  DISCONNECTED : 2,
  RECONNECTING : 3
};
...
ConnectionChannel.prototype.getChannelState = function()
...

This now did make the enum part of the “ConnectionChannel” class. The usage of this enum is simple too:

...
var myChannelObject = ...
if(channelObject.getChannelState() == ConnectionChannel.ChannelStates.CONNECTED)
{
  // do some work here...
}
else
...

Replacing Woodstock’s JSF components with ADF Faces

I didn’t notice that SUN plans to no longer support their Woodstock components, perhaps b/c I don’t follow this project close enough.

Some of my colleagues at Oracle was putting together a pretty nice overview on how to replace that component set with ADF Faces.

You can find the matrix here:

http://www.oracle.com/technology/products/adf/adffaces/woodstock2adfMatix.html

UPDATE:

Shay did another entry based on this topic, see here.

Introduction to Oracle’s ADF Faces Rich Client Framework

My introductionary article on Oracle’s ADF Faces Rich Client was published by DZone today. It is here. I hope you enjoy it.

Are you using Apache MyFaces Trinidad ?

Just took a look HERE and saw that more than 40 companies are already listed here. They are using Trinidad on their consulting gigs or for the projects or even products.

If you are using Apache MyFaces Trinidad, let us know and your company (and/or customer) to this list.

Patterns for rich web UIs – table with large data set

In “old” web application it was pretty common that there has to be a paginator to navigate through the large data set. Instead of presenting tons of rows (bad UI!) a NEXT/PREV link was next to the table for getting more data. Almost every table “component” has that (e.g. displaytag, tons of 3rd party JSF libraries, Rails,…) these days.

With “Ajax” and “WEB 2.0″ this pattern is not dead (e.g. see twitter, google, …), but a different pattern on handling larger data sets is getting more and more attention. The data is loaded when the user is scrolling down to the “end” of the table. As soon as the *visible* data is almost presented an eventhandler (on the scroller) is using Ajax to fetch new data, to be displayed once loaded.

Two examples that are following these patterns are ADF Faces Rich Client (a cool JSF library) and DZone.

Sure, both patterns are valid in different usecases and the “new” option is pretty cool enhancement to rich web UIs.

Apache MyFaces – a pretty active community

When I had to write the first quarterly report of the Apache MyFaces community (I am now the new chair, after Manfred Geiler decided to “retire”) I noticed that this community was able to have 11 releases, on all the different subprojects, over the last three month. Pretty cool, isn’t it ?

Here is the list of releases:

• MyFaces Core 1.2.5
• MyFaces Tomahawk 1.1.8
• MyFaces Tobago 1.0.19
• MyFaces Tobago 1.0.20
• MyFaces Trinidad 1.0.10
• MyFaces Trinidad 1.2.10
• MyFaces Orchestra 1.3
• MyFaces Extensions Validator 1.1.1
• MyFaces Extensions Validator 1.2.1
• MyFaces Portal Bridge 1.0.0-alpha-3
• MyFaces Portal Bridge 1.0.0-beta

Not only the community managed to release new bits, the community also continued the way to a JSF 2.0 implementation (the implementation project already started in September/October 2009). Also a discussion on a “global” skinning module (eventually useful in JSF 2.0 land?) was discussed.

I am pretty happy that this community is really doing well, after all the years

Thanks to every single contribution to the overall community.

New Google Chrome browser…

Read somewhere, that there is a new Google Chrome browser out… Wonder if that fixes some of the issues (-> work arounds) I had to do… At least the new version is suppused to have a more recent webkit “kernel”.

All these “cool” browser updates… so 1995……

hacks for http streaming

When working on Comet solutions, the sooner or later you have to do some browser hacks… When doing http streaming for the “push”, it is common to use an iframe as the source of the streaming conent. On the server you render the “update data”, when ever it is present. The browser is basically doing an incrementally rendering.

This works so far in most of the browsers, like Firefox2, IE7 or the latest greatest (-> nightly) WebKit. But not on Safari 3.2.1 or Google Chrome. To make them happy, I had to make the response a bit longer, by adding some bogus extra HTML…