Twitter status post with Apache Wink

I read from Davanum Srinivas’s tweet that the Apache Wink podling released 0.1. I didn’t know what Wink is offering, so I took a look. I read that Apache Wink 0.1 is a complete and TCK compliant implementation of the JAX-RS v1.0 specification. Also the documentation is quite large, I am impressed.

So, I gave it a try to post some status updates to Twitter. Here is a five to ten minute try/error hack by combining Apache Wink and Twitter:

package net.wessendorf.twitter.client.app;

import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.MultivaluedMap;
import org.apache.wink.client.ClientConfig;
import org.apache.wink.client.Resource;
import org.apache.wink.client.RestClient;
import org.apache.wink.common.internal.MultivaluedMapImpl;
import sun.misc.BASE64Encoder;

public class App
{
  public static void main( String[] args )
  {
    ClientConfig cc = new ClientConfig();
    cc.proxyHost("iam-behind-a-proxy.com");
    cc.proxyPort(80);

    String logon = "username:password";
    String encodedLogon = new BASE64Encoder().encode(logon.getBytes());

    RestClient client = new RestClient(cc);
    Resource twitter =
 client.resource("http://twitter.com/statuses/update.json");

    twitter.header("Authorization", "Basic " + encodedLogon);
    twitter.contentType(MediaType.APPLICATION_FORM_URLENCODED_TYPE);
    twitter.accept(MediaType.APPLICATION_JSON_TYPE);

    MultivaluedMap<String, String> msg =
 new MultivaluedMapImpl<String, String>();
    msg.add("status", "Hello Apache Wink!");

    twitter.post(String.class, msg);
  }
}

This is really simple form but, heck it is just a try/error hack. Please note that this “programm” requires the SUN JDK, as I was using the BASE64Encoder class. By default Apache Wink uses the HttpURLConnection class (from your JDK) -  but there is also a library for Apache Http Client 4.0.

The documentation is online.

Issues with “in” operator in JavaScript – using hasOwnProperty() function

Imagine you are using an JavaScript array on the client-side that stores some client-side components (or vanilla HTML elements) by their IDs – for what ever reason. Now imagine you have a function that checks if a given ID is in that particular array. Based on the result, some (different) logic is triggered. Pretty common scenario – nothing fancy.

Code could look like this:

var componentIds = new Array();
componentIds["table"] = "my table component";
componentIds["tree"] = "my tree component";

containsComponent = function(compId)
{
  if((compId in componentIds))
  {
    return true;
  }
  else
  {
    return false;
  }
}

//some callings callings...
alert("tree: in array ? -> " + containsComponent("tree"));
alert("myTabe: in array ? -> " + containsComponent("myTree"));
alert("table: in array ? -> " + containsComponent("table"));

Now I noticed some problem when your component ID is a “reserved” word. Like “map” or “push”. Does that ring your ear ? Yes, correct – that’s the name of a JavaScript function of the Array class:

// huh ???
alert("map: in array ? -> " + containsComponent("map"));
 

So that means on an empty array a check for “map” (or “slice”) would return TRUE. That can cause some interesting troubles and side effects, well BUGs

The problem with “in” operator is that it does not only check if the damn array does have a key with the “name” in question – it also checks for functions on the prototype. I talked to my colleague Blake Sullivan about avoiding to query for the function. He simply suggested to just use the “hasOwnProperty()” function instead of checking if the returned value is type of “function”. I personally never used that function before (and never seen it in code before) – but it helps to avoid odd and nasty issue

What’s New in JSF 2?

Andy Schwartz has created a fantastic introduction to the new features of JavaServer Faces 2:

• http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

MyFaces 2.0 is now trunk

The Apache MyFaces project started to work an implementation of the new JavaServer Faces 2.0 spec pretty early. The Apache/JSF community is driving this new effort. All recently added committers actually contributed stuff to MyFaces 2.0.

Now, there is also another important step into the JSF 2.0 adaption. Apache MyFaces has made its 2.0 effort to become trunk. This happened a few weeks ago; before the JSF 1.1 stuff was trunk. Well, we still support JSF 1.2 and JSF 1.1 (there haven’t been JSF RI releases for JSF 1.1 in a while) and continue support for these types, as they are in use.

However, JSF 2.0 brings a lot of new stuff to the table – and this spec (and its features) is really important to keep JSF alive. The MyFaces community honors that by making it TRUNK.

Good time! Now do a svn check-out and start contributing to it!

Firefox 3.5 – cool upload done with XHR and progress bar

For some reason I was reading the XHR documentation for FF.

As I noticed that there is now an upload property, that new attribute immediately got my interest and I found a pretty cool blog entry on how to write an XHR-based upload + progress-bar.

The cool thing is that is uses already today API’s of the upcoming FileUpload enhancement of the W3C. Therefore it is likely that Safari/WebKit/Chrome will have that soon too (or they do already?!)

(browser) window talks

I gave a talk about Comet and its future during AjaxWorld, in New York City. I talked about some shortcuts of current solutions including connection limits. Some solutions use a separate “channel” per window to receive updates from the server. Some are done a bit more elegant and some aren’t. But basically you have several connections from the browser to the server, no matter if they do concurrent long-polling or a fallback to periodic polling.

In ADS, the “push” solution for ADF Faces Rich Client, we actually have only one channel per browser. The window that holds the channel is the master window. It receives all updates for its “slave” windows too. Under the hood we use some JavaScript to actually talk to the different window and to dispatch the payload to the window, that should get the new data. For that we use some window/page ID algorithm…

Since always I get questions on how we actually do it, I thought that providing a simple example may help… Imagine the following two HTML pages (just vanilla JavaScript and HTML):

first page, that has the window id “w1″:

<html>
<script>
window.name = 'w1';

changeWindow = function()
{
  var w2 = window.open("", 'w2',
  "height=1,width=1,top=0,left=0,status=no,toolbar=no,menubar=no,location=no");

  if(w2.FOO != undefined)
  {
    w2.FOO.pushData("YEAH");
  }
  else
  {
    w2.close();
  }
}
</script>
<body>

<button onclick="changeWindow();">change window 2</button>
</body>
</html>

second page with window id “w2″:

<html>
<script>
window.name = 'w2';
function Pusher()
{}
Pusher.prototype.pushData = function(data)
{
  document.getElementById("divToChange").innerHTML = data;
}
var FOO = new Pusher();
</script>
<body>
<div id="divToChange">
  Hallo
</div>
</body>

</html>

Now deploy these two pages on an HTTP server, like Apache httpd (it does not work locally – due to security) and open both. Best would be page1 in one Firefox window and page2 in another Firefox window. By having different windows you can easily observe the changed HTML later on…

Now, click the button in the first page and notice the HTML is changed… This happens because we get a reference to the second window and check if some special JavaScript object is present in that particular window. If so, we push some data (that could be payload from the server, via Comet) to the other window. The JavaScript function on the second window applies the data into the DOM. That’s all!

So some may now think that is kinda hacky, well yes, but it works. However, the good news is that in HTML5 there will be a more standard solution to have cross-window-communication possible. Interesting future. For comet and web-developement!

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.