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.
Monday, January 30, 2012
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:
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.
Tuesday, January 10, 2012
Node.js + CouchDB
http://nodetuts.com/tutorials/30-couchdb-and-nano.html#video
> 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 ] }
Thursday, January 5, 2012
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 ... :(
Monday, January 2, 2012
[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:
- 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.
- 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.
- 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.
AspectJ vs Javassist
AspectJ:
Advantages:
Javassist:
Advantages:
- Very powerful, can do nearly anything you might need
- Powerful pointcut expressions for defining where to inject an advice and when to activate it (including some run-time checks) – fully enables DRY, i.e. write once & inject many times
- Both build-time and load-time code injection (weaving)
- The modified code depends on the AspectJ runtime library
- The pointcut expressions are very powerful but it might be difficult to get them right and there isn’t much support for “debugging” them though the AJDT plugin is partially able to visualize their effects
- It will likely take some time to get started though the basic usage is pretty simple (using @Aspect, @Around, and a simple pointcut expression, as we will see in the example)
Javassist:
Advantages:
- No run-time dependencies if build-time weaving used (load-time weaving requires the GluonJ agent library or gluonj.jar)
- Simple Java syntax using GlutonJ’s annotation – though the custom syntax is also trivial to understand and easy to use
- Easy, automatic weaving into the target classes with GlutonJ’s JAR tool, an Ant task or dynamically at the load-time
- Support for both build-time and load-time weaving
- An aspect can modify only a single class, you cannot inject the same piece of code to multiple classes/methods
- Limited power – only provides for field/method addition and execution of a code instead of/around a target method, either upon any of its executions or only if the execution happens in a particular context, i.e. when called from a particular class/method
Sunday, January 1, 2012
CoffeeScript vs Google Dart
Learn Javascript
- The best way to learn (and debug) Coffeescript
- Dart is similar enough to JS but far less common. You will come across more JS than Dart.
- To understand why CoffeeScript exists, and how Dart differs.
Use Coffeescript
- CoffeeScript is out there in projects already, so there's community and experience.
- CoffeeScript might come up at work sooner than Dart (esp. with Rails).
- CoffeeScript is nice!
Check out Dart
If you understand Javascript, and use CoffeeScript, and have checked out Dart, you'll be in a good position to judge which hammer is best for the task. Most JS/CS knowledge should be transferrable to Dart, the other way around would be more difficult.
[But why the JavaScript generated by Dart is so HUGE ???] - Use Frog compiler instead of DartC to compile/generate smaller JavaScript.
While Dart is pretty neat and backed by Google, it has not be absorbed into the web-applications development community like coffeescript has (coffeescript is the suggested front-end development language of the Rails core team and the preferred front-end language of the ruby community). Coffeescript also has wider support tools and, in my personal opinion, more readability. However, if that does not have you convinced then you can take a look at this ‘Hello World’ program written in Coffeescript and compiled to Javascript then Dart compiled to Javascript (taken from this gist).
Long story short, Dart supposedly offers enhanced security in your front-end (hence all the added junk?) and is more catered to large-scale projects but I won’t be reaching for Dart in the near future. The language syntax is cool and liken to Java but all the useless generated code really makes it hard for me to understand what is going on under the hood. Why use 17K lines of code when 11 will do?
http://blog.brandonmathis.me/blog/2011/10/11/dart-or-coffee/
Google Dart vs Javascript
The fundamental problem with HTML5 is JavaScript, which is not an ideal language for enterprise application development.
Google recognises this issue. An internal email from Nov 2010 that outlines their strategy for ‘Dart’, says:
“Complex web apps–the kind that Google specializes in–are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems”
In the past Google has used Java to JavaScript compilation (GWT) and annotated-JavaScript to JavaScript compilation (Closure) to overcome these problems. In my previous blogpost I speculated that Microsoft could use a similar approach, offering a C# / VB.NET to JavaScript compiler, allowing HTML5 developers to use the full power of Visual Studio. However, with Dart Google are looking to go one step further:
“The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform.”
That’s quite an ambituous goal!
http://www.scottlogic.co.uk/blog/colin/2011/09/dart-will-google-make-html5-applications-viable/
Subscribe to:
Posts (Atom)