ARC forbids explicit message send of ‘retain’

To get rid of this error you need to disable ARC, but how? I found this link which show how to disable it for cetain source files, but I wanted this to be a global setting.

My Kaazing colleague Richard Clark told me how to turn off ARC at the project level. Here is what you need to do in Xcode:

1. Select your project file.
2. You should be in the “Build settings” tab. Select the “levels” option (default is “Combined”)
3. There’s a search field to the right of “Combined”. Enter “Automatic”
4. Second group should be “Apple LLVM Compiler 3.0 – Language”. Second line under that controls ARC.
5. Click that line, then in the middle column (where it says “yes”), click and choose “no”.

Thanks Richard

The last 2.5 days I spent some time in learning about Objective C. I used Xcode (an IDE for the Mac) and also a pretty straightforward (or minimalistic) enviroment:

• text editor
• compiler

All you really need for coding some Objective-C is a text-editor and a compiler. On my Mac I used TextMate and the gcc compiler. Sure, with Xcode iOS/Objective-C development is nicer, but a with a text editor and a compiler you get something in a short amount of time as well. (Note: Xcode is only available for Mac OS)

Using the gcc compiler I noticed a few issues, when actually compiling the bits, since I was never doing any C/C++ development before. The main reason for writing this blog is giving a quick introduction that also includes the required gcc commands…. – as there are already a lot of “Hello World”-ish blogs.
For professional iOS development I do recommend using Xcode, but let’s get started…

The canonical “Hello World” is simple and looks like:

#import <Foundation/Foundation.h>

int main(void) {
	NSLog(@"Hello Objective-C");

	return 0;
}

The NSLog() function requires a NSString object. The String starts with an @, this identifies the string as a NSString object… Save the above as hello.m and compile it:

gcc hello.m -o prog -framework Foundation

It is important to specify that you are using the Foundation classes (-framework Froundation)…
Now you can invoke your first program:

./prog

Now let’s take a look at a simple class. For that we need two files: a header file and it’s implementation (or method) file. Let’s take a look at the MyPerson.h file:

#import <Foundation/Foundation.h>

@interface MyPerson : NSObject {
}

// getter and setter
@property (nonatomic, copy) NSString* firstName;
@property (nonatomic, copy) NSString* secondName;

// should print the complete name
- (void) printDetails;

@end

The MyPerson class extends the NSObject class and it defines a few setter/getter, by using Objective-C’s property syntax. I also has another method to print out the name of an instance of this class. The MyPerson.m file looks like:

// usage of our header file
#import "MyPerson.h"

@implementation MyPerson

// getter/setter
@synthesize firstName = firstName_ ;
@synthesize secondName = secondName_ ;

// the actual method
- (void) printDetails {

    // write out the name, in a formated way:
    NSLog(@"%@, %@", self.secondName, self.firstName);
}

@end

In here we basically implement the defined methods, like the getter/setter or the printDetails.

Now we want to use the MyPerson class, which is done in the main.m file:

#import <Foundation/Foundation.h>
#import "MyPerson.h"

int main(void) {
	// memory mgmt class
	NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    // autorelease to avoid leaks
    MyPerson* matze = [[[MyPerson alloc] init]autorelease];

    matze.firstName =  @"Matthias";
    matze.secondName = @"Wessendorf";

    [matze printDetails];

    // free the memory
	[pool release];
	return 0;
}

The main.m file imports our MyPerson class and its main() function creates an object of the class and sets values to the instance by using the two setter functions. Afterwards the printDetails is called to print the first and second name to the console. It also uses the NSAutoreleasePool class, for some memory management… The compilation is done with the following command:

gcc main.m MyPerson.m -o prog2 -framework Foundation

You can now invoke the prog2!

Thanks to Torsten Curdt! He was around when I had some newbie questions. Thanks!

A simple TCP-based echo server

Since the WebSocket client API itself is not enough (to build a “real” application), we need some (existing) backend, or server. A very simple example would be to bring a (TCP) echo server to the browser, via WebSocket:

var net = require('net');

var server = net.createServer(function (socket) {
  socket.write("Echo server\r\n");
  socket.pipe(socket);
});

server.listen(1337, "127.0.0.1");

The above code is a VERY simple “EchoServer” that runs on port “1337″. It is in Node.js. The code is borrowed from their website.

Bring it to the Web

To be able to access this TCP server with a WebSocket application you need to add the following configuration to the Kaazing WebSocket Gateway:

<service>
  <accept>ws://localhost:8000/echo</accept>
  <connect>tcp://localhost:1337/</connect>
  <type>proxy</type>
  <cross-site-constraint>
    <allow-origin>*</allow-origin>
  </cross-site-constraint>
</service>

The entry point for the echo server is the ws://localhost:8000/echoURL. The Gateway connects the WebSocket connection to the backend (check the tcp port). The connection to the echo server is straightforward. The following shows a pretty simple JavaScript program, that opens a WebSocket connection in order to send and receive data from the underlying TCP server:

var websocketConnection = new WebSocket("ws://localhost:8000/echo");
websocketConnection.onopen = function(ev) {
	console.log('Connected to the echo service')
};
websocketConnection.onmessage = function(event) {
  var payload = event.data;
  displayEcho(payload);
};
...
websocketConnection.send("Hello Echo Server");
...

This is obviously a simple example, but it clearly shows the power of WebSocket! Give it a try!

If you are interested in HTML5 and WebSocket, check out the Kaazing Gateway! BTW. Kaazing is hiring…

You can try this out as well – The steps are quite simple:

• Download the JMS Edition of the Kaazing gateway and extract it
• Start the included Apache ActiveMQ server
• Start the gateway itself
• Start the demo stock ticker feed

...
var stompConnectionFactory =
        new StompConnectionFactory( "ws://localhost:8000/jms");

// create a connection, by using a JS callback
var connectionFuture =
   stompConnectionFactory.createConnection(user, passwd, function () {

    if (!connectionFuture.exception) {
        connection = connectionFuture.getValue();
        // register a JMS exception handler
        connection.setExceptionListener(handleException);

        // create session
        session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        // create a topic
        topic = session.createTopic("/topic/destination");

        // creating some consumers!
        var consumer1 = session.createConsumer(topic);

        // attach the callback that receives the stock prices:
        consumer1.setMessageListener(handleMessageCallback);

        // start!
        connection.start(someCallback);
    }
....
});

• we receive the actual connection
• we setup a JMS exception handler
• we create a session, a JMS topic and a consumer
• we register a handler for the incoming JMS messages (handleMessageCallback)
• we finally start the connection’s delivery of incoming messages

The handleMessageCallback() is used to receive the stock prices and to “draw” the DTHML, so that the stock changes are nice to watch in a vanilla HTML table, like below:

The code for the message listener is also using our JavaScript JMS API, to receive JMS (Text)messages:

function handleMessageCallack(message) {

  // did Apache ActiveMQ send us a JMS TextMessage?

  if (message instanceof TextMessage) {
     var body = message.getText();

     // DHTML code to show stock values...

  }
}

The above JavaScript code is pretty much readable for every JMS coder. The big news is that the JMS communication from the ActiveMQ to the browser (and vice versa) happens over WebSocket. This dramatically reduces overhead and latency for your web application!

The WebSocket gateway is not limited to Stomp/JMS, it has support for other protocols like AMQP, or even XMPP as well!

If you want to try (or see) this stock ticker, you can! It is part of the Kaazing JMS demo bundle. Once you installed the gateway, you can see the stockticker on your machine…

Have fun!

However WebSocket is NOT:

• just a better Ajax or XHR, nor was it designed to be!
• designed to be a one-size-fits-all replacement for HTTP!

When you build typical client-server applications you are using higher level protocols and APIs, such as XMPP, JMS or JDBC instead of raw TCP socket. You should think of WebSocket the same way! Instead of exchanging raw WebSocket data between the browser and the server (and introducing your own “protocol”), but you should use WebSocket to run these high level protocols on top of it! In fact the Kaazing WebSocket Gateway allows you to do this!

Here is an example that shows how to extend a (NodeJS-based) UDP program to the browser, by using the Kaazing WebSocket gateway.

Getting ready with NodeJS and the Kaazing gateway

1. Download the Kaazing WebSocket Gateway (HTML5 Edition)
2. Download and install NodeJS (only needed for this demo…)

The installation of the Kaazing WebSocket Gateway is quite esay: Unzip the archive and launch the gateway.start command in $KAAZING_HOME/bin. That’s it.

Now we can write pretty simple and straightforward UDP program, in Node:

var Buffer = require('buffer').Buffer;
var dgram = require('dgram');
// create the datagram socket
var sock = dgram.createSocket("udp4");
// some bogus news...
var news = [
   "Borussia Dortmund wins German championship",
   "Tornado warning for the Bay Area",
   "More rain for the weekend",
   "Android tablets take over the world",
   "iPad2 sold out",
   "Nation's rappers down to last two samples"
];
function broadcastNew() {
   var buf = new Buffer(news[Math.floor(Math.random()*news.length)]);
   sock.send(buf, 0, buf.length, 55555, "127.0.0.1");
   console.log("Sent " + buf + " to the wire...");
}
setInterval(broadcastNew, 3000);

The program is simple: Every three seconds it throws some data to its UDP connection (localhost:55555) and it logs the same message to the server console. You can run the broadcasting “server” with node yourFilename.js.

Next you need to add the following section to the gateway-config.xml file:

<service>
  <accept>ws://localhost:8000/nodejs</accept>
  <type>broadcast</type>
  <properties>
    <accept>udp://localhost:55555</accept>
  </properties>
  <cross-site-constraint>
    <allow-origin>*</allow-origin>
  </cross-site-constraint>
</service>

This maps any incoming WebSocket request for ws://localhost:8000/nodejs to the UDP tool we started on localhost:55555. The used cross-site-constraint ensures that you can invoke the Gateway from a different origin (e.g. different port). If you check the other configured Gateway services you see they do contain URIs for the cross-site-constraint parameter…

The missing piece here is a VERY simple WebSocket script, like:

<!DOCTYPE html>
<html>
  <head>
    <title> My first WebSocket app!</title>

<script src="./WebSocket.js"></script>

<script type="text/javascript">
function connectMeToNodeByUsingKaazing() {
  var ws = new WebSocket("ws://localhost:8000/nodejs");
  ws.onopen = function(ev) {
     console.log("connection is up");
};
ws.onmessage = function(ev) {
     console.log("The news: \"" + ev.data + "\"");
};
}
</script>
<body onLoad="connectMeToNodeByUsingKaazing()">
<h2>Open your JavaScript console to see the messages!</h2>
</body>
</html>

Now go to the $KAAZING_HOME directory and cd to “web/extras”:

1. create a new folder in there (e.g. mkdir firstApp)
2. copy the WebSocket.js file (from $KAAZING_HOME/lib/client/javascript/WebSocket.js) to the new ‘firstApp‘ folder.
3. make sure the above HTML page is in that directory as well (e.g. simpleUDP.html)

That’s it!

If you now open that HTML page in a browser (e.g. http://localhost:8001/firstApp/simpleUDP.html) (and open the JavaScript console), you will see that the connection to the Kaazing gateway has been opened and that news items are coming across the wire!

The sweet part is that you have now been able to bring a UDP based communication to the browser, by using the Gateway server! Of course the demo is pretty simple and trivial, but it opens up for what’s possible when running the Kaazing gateway.

In fact the Kaazing WebSocket Gateway does already have support for JMS, XMPP, STOMP or even AMQP. You can now easily bring these backends to the web (including browsers like IE6)!!!

Have fun!

The Kaazing WebSocket Gateway is an advanced WebSocket server, which contains several Client SDKs, including a Java-based WebSocket client!

After downloading and extracting the Kaazing WebSocket Gateway, you find the Java API inside the lib/client/java folder. Add the JAR to a (blank) Java Project in your IDE (e.g. Eclipse).

A pretty quick (and simple) test is using the API against the public Echo-Server, hosted at websocket.org,like:

package net.wessendorf.kaazing.gateway;

import java.net.URI;
import com.kaazing.gateway.client.html5.WebSocket;
import com.kaazing.gateway.client.html5.WebSocketAdapter;
import com.kaazing.gateway.client.html5.WebSocketEvent;

public class WebSocketTest {

  public static void main(String[] args) throws Exception {
    final WebSocket ws = new WebSocket();
    ws.addWebSocketListener(
          new WebSocketAdapter() {
     @Override
     public void onMessage(WebSocketEvent messageEvent) {
         System.out.println("Received Event Data: " + messageEvent.getData());
         // let's close the open connection...
         try {
             ws.close();
         }
         catch (Exception e) {
             e.printStackTrace();
         }
     }
     @Override
     public void onOpen(WebSocketEvent openEvent) {
         System.out.println("Connection to Server is up!");
          // we are able to talk to the WebSocket gateway
         try {
             ws.send("Hey, server!");
         }
         catch (Exception e) {
             e.printStackTrace();
         }
            }
          }
        );
        ws.connect(new URI("ws://echo.websocket.org:80"));
    }
}

The Java code is pretty straightforward: It creates a WebSocket object, overrides a convenience class to react on some WebSocket events and finally connects to the actual Echo-Server.

Once the connection is up (inside the onOpen() callback), we are sending a simple text to the server. The server returns exactly the same string back to the sending client. This issues our onMessage() callback. After printing the received data to the console, we close the open connection.

Instead of using the remote server, you could try the demos on your machine, by installing the Kaazing WebSocket Gateway on your box!

Have fun!

In March I am joining Kaazing! I will be working on WebSocket, HTML5 and other related technologies to build the next generation web!
I am really excited about it and I am looking forward to start my new adventure there!

Thanks!
Matthias

Of course, you can also use JPA inside of the CloudBees offer. I’ve tested it with EclipseLink and OpenJPA.

In order to use JPA with the hosted database, you need to include something like below, in your persistence.xml file:

<persistence-unit
  name="myUnit"
  transaction-type="RESOURCE_LOCAL">

<class>my.PersistentObject</class>
...

 <properties>
<!-- JPA standard properties -->
<property
   name="javax.persistence.jdbc.driver"
   value="com.cloudbees.jdbc.Driver"/>
<property
   name="javax.persistence.jdbc.url"
   value="jdbc:cloudbees://YOURSCHEMA"/>
<property
   name="javax.persistence.jdbc.user"
   value="USER"/>
<property
   name="javax.persistence.jdbc.password"
   value="PASSWORD"/>
....

That’s all you need! Now you are able to use the database!

Note: For your local development you can also access the DB via a real URL and the regular MySQL driver. The management console does show the remote connection details as well.

As I am leaving Oracle, I won’t participate actively in JSF related projects anymore. Therefore I am also step back from being the Apache MyFaces PMC Chair.

I will be moving on to work on some really exciting stuff! I am looking forward to my new adventure!

java.io.NotSerializableException:
org.apache.myfaces.trinidad.component.UIXSwitcher

No, this is not a bug at all!

First:
Your (session/application/pageFlow scoped) backing beans should not have an UI component as its property… (if you really really need the “cool” binding attribute).

Second:
UIComponents are not serializable – for a good reason!
In JSF there is StateSaving (see the restore/saveState() hooks)….

Apache MyFaces Trinidad does have a tool that helps to store an reference to an UIComponent (instead of the component itself).

Here are a few blogs on that, that may give more information on the API and why the tool is there:

http://matthiaswessendorf.wordpress.com/2010/03/31/uicomponent-references-in-session-scoped-jsf-beans/

http://leadingyouastray.blogspot.com/2010/02/references-to-uicomponents-in-session.html

Have fun!