Apache TomEE

http://openejb.apache.org/apache-tomee.html

TomEE
The Web Profile version of TomEE contains
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache Bean Validation

TomEE+
The TomEE Plus distribution adds the following:
JAX-RS - Apache CXF
JAX-WS - Apache CXF
JMS - Apache ActiveMQ
Connector - Apache Geronimo Connector

Goal
Simple, Get more from Tomcat without giving anything up.

Nodejs vs Play for Front-End Apps

http://www.subbu.org/blog/2011/03/nodejs-vs-play-for-front-end-apps

We often see “hello world” style apps used for benchmarking servers. A “hello world” app can produce low-latency responses under several thousands of concurrent connections, but such tests do not help make choices for building real world apps. Here is a test I did at eBay recently comparing a front-end app built using two different stacks:

• nodejs (version 0.4.3) as the HTTP server, using Express (with NODE_ENV=production) as the web framework with EJS templates and cluster for launching node instances (cluster launches 8 instances of nodejs for the machine I used for testing)




• Play framework (version 1.1.1) as the web framework in production mode on Java 1.6.0_20.
  

The intent behind my choice of the Play framework is to pick up a stack that uses rails-style controller and view templates for front-end apps, but runs on the JVM. The Java-land is littered with a large number of complex legacy frameworks that don’t even get HTTP right, but I found Play easy to work with. I spent nearly equal amounts of time (under two hours) to build the same app on nodejs and Play.

Node.js + CouchDB

http://nodetuts.com/tutorials/30-couchdb-and-nano.html#video

http://npmjs.org/

> cat package.json

{

"name": "Node_tutorial",

"description": "My test node tutorial",

"version":"0.1.0",

"author": "David Chang",

"dependencies": {

"nano": "1.1.x"

}

}

> npm install

> cat couch.js

var nano = require('nano');

var server = nano('http://XXX:YYY@dmak168.iriscouch.com');

server.db.create('mydb2', function(err){

if (err) { throw err; }

console.log('created mydb');

var doc1 = { a:1, b:2, c: "abd", d: [1, 2, 3] };

var db = server.use('mydb2');

db.insert(doc1, "doc_two", function(err){

if (err) { throw err; }

console.log('inserted obj1');

db.get('doc_two', function(err, val) {

console.log('doc_two = ', val);

});

});

});

> node couch.js

created mydb

inserted obj1

doc_two = { _id: 'doc_two',

_rev: '1-f83339c44679257161b912dd6aad89dd',

a: 1,

b: 2,

c: 'abd',

d: [ 1, 2, 3 ] }

Lucky number

Hooray for the lucky number I just got ... quadruple lucky 7

HTML5 on Google Chrome

This is a screenshot captured on Google Chrome(v9.0.597.107), it worked smoothly for 10+ minutes and then became unresponsive permanently ... :(

[Play!] keep the model stateless

Keep the model stateless

Play is designed to operate in a ‘share nothing’ architecture. The idea is to keep the application completely stateless. By doing this you will allow your application to run on as many server nodes as needed at the same time.

What are the common traps you should avoid to keep the model stateless? Do not store any object on the Java heap for multiple requests

When you want to keep data across multiple requests you have several choices:

1. If data is small and simple enough, store it into the flash or the session scope. However these scopes are limited to about 4 KB each, and allow only String data.
2. Save the data permanently into persistent storage (like a database). For example if you need to create an object with a “wizard” that spans multiple requests:
   • Initialize and persist the object into the database at the first request.
   • Save the newly-created object’s ID into the flash scope.
   • During successive requests, retrieve the object from the database using the object ID, update it, and save it again.
3. Save the data temporarily into a transient storage (such as the Cache). For example if you need to create an object with a “wizard” that spans multiple requests:
   • Initialize the object and save it into the Cache at the first request.
   • Save the newly-created object’s key into the flash scope
   • During successive requests, retrieve the object from the cache (with the correct key), update it, and save it into the cache again.
   • At the end of the last request in the chain, save the object permanently (into the database for example)

The Cache is not a reliable storage but if you put an object in the cache you should be able to retrieve it. Depending on your requirements, the Cache can be a very good choice and a good replacement for the Java Servlet session.

http://www.playframework.org/documentation/1.2.4/model

Great presentations @ Parleys.com

http://www.parleys.com/#st=4&id=102998