If you run "java -jar killer-app.jar" on a machine where JavaFX SDK was installed with a simple "unzip" (like a Mac), you will get the following error:

Unable to read ../rt/lib/jfxrt.jar
Unable to read ../../../../rt/lib/jfxrt.jar
Unable to read ../../sdk/rt/lib/jfxrt.jar
Unable to read ../../../artifacts/sdk/rt/lib/jfxrt.jar

Because the Java FX launcher does not know where to find the runtime, it falls back to the default location.
To solve this problem, just pass the system property: javafx.runtime.path with the JavaFX SDK location at start:

java -Djavafx.runtime.path=[THE UNZIPPED JAVA FX SDK]/rt -jar killer-app.jar
*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

Apache TomEE is an opensource, Java EE 6 WebProfile certified, easy to install Java EE 6 server.
The test:

1. Download size (apache-tomee-plus-1.0.0-beta-2.zip ): 43.8 MB (it is the biggest available download. It contains the Java EE 6 WebProfile with some "full profile" functionality)
2. Installation = Unzip
3. Disc size: 50.9 MB after installation
4. Startup: same as tomcat: ./startup.sh
5. Full deployment of ServerSmokeTest took < 2 secs.
6. Tested were: Stereotypes (encapsulating @Named and @RequestScoped), @RequestScoped, @Named CDI-Beans, Injection of EJB 3.1 (no interface view), into CDI bean, @Singleton,@Stateless, CDI-events, POJO-injection, Interceptors
7. ServerSmokeTest works without any modification on Glassfish v3, WebLogic 12c, JBoss 7.0.2, JBoss 6m5, SIwpas-1.0.0-CR4, resin-4.0.12 and even in the openshift cloud.

First impression: good. Easy to install, fast deployment, no problems. TomEE is another reason to get rid of the complicated and bloated Plain Old Web Containers :).
*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

The exception:

SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IllegalArgumentException: object is not an instance of declaring class
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
	at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
	at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
	at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
	at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
	[…]

is caused by exposing EJB 3.1 methods directly via REST without having a no-interface view declared. This happens when your EJB 3.1 REST-endpoint implements an additional interface without declaring the no-interface view:

import javax.ejb.*;

@Path("RESTafari)
@Singleton
public class RESTEndpoint implements SomeLocalInterface{}

Adding a @LocalBean annotation (and activating the no-interface view) solves the problem:

import javax.ejb.*;

@LocalBean
@Path("RESTafari)
@Singleton
public class RESTEndpoint implements SomeLocalInterface{}

*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

JavaFX 2.0 SDK is available for Linux as Developer Preview Download. Enjoy FX-ing!
*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

1. In this free event at 26.01.2012 in Munich: JavaFX 2.0, Lean, Productive and Maintainable I would like to explain why Java FX rocks and what happens, if you combine Java EE with Java FX.
2. Session: "Less Patterns Is More - With Java EE 6",26.01.2012, 14:30-15:30 in Munich (OOP Conference)
3. Workshop: "Java EE 6/7 Best Practices", 27.01.2012, 9:00-16:00 in Munich (OOP Conference)
4. Real World Java EE 6 Bootstrap Workshop, Airport Munich, at 12.03.2011 There are already sufficient registrations--it will definitely take place. One day is more than enough to become really productive with Java EE :-)

*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

Got an interesting question:
Lets say you have an EAR archive which contains 3 EJB projects: one project that contains @Local interfaces that are the facades for all three EJB's. The idea is that all 3 of them can communicate with each other using that project as a dependency.

Or:

The second way is to have for each EJB Project one additional project that has the facade @Local interface and each EJB project to depend those who needs. Which is better?

This question is impossible to answer because the reason for the modularization of the EAR is unknown. Before you are going to think about modularization I would start with answering the following questions:

1. How often do you have to partially deploy contents of the EAR?
2. Is it likely that you will NOT deploy the interface JAR, but only the "implementation" JARs? Why you are doing that?
3. How often are you going to change the implementation without recompiling the interfaces?

Without explicit modularization requirements I would package all the clearly separated modules, components and projects into one, big, single EJB-JAR inside the WAR. In Java EE 6 I would use (see: Is Java EE 6 War The New EAR?) The Pragmatic Modularization And Packaging) WAR-packaging and put all the components into a single JAR or even into the classes folder. With Maven you could use the: jar-with-dependencies assembly configuration. If you are still developing with the ancient Java EE 5, I would create a "everything" EJB-JAR and an "everything" WAR inside the EAR.

If you are going to implement an API, which is going to be implemented by several JAR-modules, I would provide a single JAR with all interface for each EJB-JAR. I would expect then to find these JARs in several EARs without any modification.

Remember: Premature Extensibility (In Java EE 6) Is the Root of Some Evil :-)

See also and How To Kill An OSGi Project - With 10 Questions
*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

All JavaFX 2 components can be styled with CSS 3. The CSS JavaFX 2 reference is available here: http://docs.oracle.com/javafx/2.0/api/javafx/scene/doc-files/cssref.html. To activate your custom CSS you only have to add a resource containing the CSS styles to the javafx.scene.Scene:

        Scene scene = ...
        scene.getStylesheets().add(this.getClass().getResource("javafxrocks.css").toExternalForm());
        stage.setScene(scene);
        stage.show();

*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]

How to deal with interfaces in Java EE 6? @Qualifiers, @Stereotypes, @Alternatives with or without interfaces are discussed in this free article: http://www.oracle.com/technetwork/articles/java/intondemand-1444614.html.

Feedback is, as always, highly appreciated!
*NEW* Real World Java EE Night Hacks - Dissecting Best Practices ...and the bestseller Real World Java EE - Rethinking Best Practices

Java EE Bootstrap Workshop [Airport Munich]