Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Saturday, April 30, 2011

You should not have any other @ManagedBean beside @Named.

14:01 Saturday, April 30, 2011 Posted by Test 2 comments:
, ,
Provocative title, I know. But this is what my mind came up with, reading about @EdBurns latest survey where the JSF EG asks the community: "Should we deprecate Managed Beans in #JSF 2.2?". Seeing the first intermediate direction from today, it's the majority of the voters (roughly 80%), which vote for removing/deprecating them.
Great indication not only for the JSF EG but also for the whole EE 7 EG. Why?

What's all this about?
It's about the Faces Managed Beans. It defines a couple of Annotations for automatically registering classes with the runtime as a managed bean class within specific scopes. Classes must be scanned for the presence of this annotation at application startup, before any requests have been serviced. As you can see from the comments, it has been planned to extract the specification for managed beans from JSF and place it into its own specification since the 2.0 (Java EE 6). If you compare the features with the ones provided by Contexts and Dependency Injection (CDI). CDI defines a set of contextual services, provided by Java EE containers, that make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but type-safe way. If you compare the scopes in javax.enterprise.context.* and javax.faces.bean.* (Weld API Docs, DI API) you see some common names. And that basically is the problem here. You can achieve mostly the same using the javax.faces.bean.ManagedBean or any javax.inject.Named with a CDI Context. This multiple solutions space not only covers JSF but also the javax.annotation.ManagedBean (API) and with it the complete platform. The ManagedBean annotation marks a POJO (Plain Old Java Object) as a ManagedBean. A javax.annotation.ManagedBean supports a small set of basic services such as resource injection, lifecycle callbacks and interceptors. It seems as if this was intended to be a first draft of the new container objects which don't have to implement interfaces or conform to any container requirements except the fact, that they have a special annotation with them.

What does it mean to remove the Faces Managed Beans?
Depending on you view onto the platform it could either be a first step into consolidation of the different ManagedBean approaches with Java EE or even a step to make JSF completely dependent on the Java EE Web Profile. If the Faces Managed Beans feature is dropped, you need any kind of Managed Bean service to the core JSF functionality. A standalone appserver which does not contain one of the mechanisms JSF will depend on (CDI/DI or EE ManagedBeans) will not be able to run it anymore. So, you decide weather or not JSF could be used without a EE profile or not.

What do the experts say?
I can only speak for myself here, rate for yourself if you still need the answer from an expert :) I personally voted for removing the Faces Managed Beans. They cause confusion with developers. Removing them force the EE 7 EG to think about a general approach for other specs being in a comparable situation (present and future). The drawback is, you will probably lose the ability to run on very lightweight Java appserver which do not conform to one of the defined profiles and can't provide DI/CDI features.
Further on, there are still complaints about the quality and performance of WELD being the RI for CDI. So, in the end, I believe a couple of actions have to be taken to make the removal of the Faces Managed Beans a success story. But it will be worth it: Looking at the complete Java EE 7 platform!

Cast your vote here! Help shape Java EE 7 and beyond!

I would love to read about your thoughts! Please take a minute to express your ideas and rating on that in the comments!

Thursday, April 28, 2011

GlassFish 3.1 clustering - Swarm intelligence - New Article in German iX Magazine

11:40 Thursday, April 28, 2011 Posted by Test 2 comments:
A short notice about my latest article about GlassFish 3.1. The recent issue of German iX magazine (05/2011) is published today and you can get a digital copy by the end of the month from their archive.
The article introduces you to the basic clustering features new in 3.1 and guides you through a simple setup. It also cleans up with some older myths and speculations about GlassFish's future.
You can order your printed copy today from the heise.de online shop.

Tuesday, April 26, 2011

JavaOne 2011 NOT back to Moscone

06:41 Tuesday, April 26, 2011 Posted by Test No comments:
Yesterday Oracle announced, what we all were expecting. JavaOne 2011 will be in the exact same place than the more or less disastrous 2010 version. It will be located in downtown San Francisco and takes place in parallel with Oracle OpenWorld. To be honest, this is not a big surprise. Did anybody expect them to move such an event within less than a year? Let's see, what's going to change and what to expect.

Source: OOW Conference Map
Like last year it will be held in the hotels around the Mason Str. This have been the Hilton as the main conference Hotel with all the keynotes and demo grounds, the hotel Nikko and the Parc 55. Seeing Alexis posting about some changes:
[...] no more wandering between hotels and Moscone, more room for JavaOne sessions with Oracle Develop being moved to another venue [...]
It seems as if this will be a complete separate conference probably with completely separate social activities. So there should be no need to wander around. I don't know if this will improve the overall experience to me personally, because I used to visit OOW, OracleDevelop and JavaOne but until Oracle decides to shift J1 to another time frame this will be my personal problem. Until today I don't really see a reference to Oracle Develop. It seems as if it's completely vanished away. They will probably make it a more closer part of OpenWorld and leave all those poor Java guys alone ;) Let's see.
As Alexis also wrote:
[...] more community involvement in the event planning, more space and time for "hallway conversations", and more sessions overal. [...]
That sounds like fun. Hey, guys, if you are reading this: I am here to help! *wink* I would love to help!

JavaOne Main Content Tracks
The content tracks cover the complete platform as expected. Sad to see, that the JavaOne program review committee still is an old list. At last one external reviewer named there, stated that he did not even got an invitation up to now. Anyway, I hope they will try to tie in some community guys, too. The Java Champions of the ACE Directors for example? Why not :)
And I am speculating that this years JavaOne will also have a huge drawback because the Google/Oracle case is still unsolved I don't expect any Googlers there ....sad.sad.sad.

  • Core Java Platform
  • Emerging Languages, Tools, and Techniques
  • Enterprise Service Architectures and the Cloud
  • Java EE Web Profile and Platform Technologies
  • Java ME, Mobile, Embedded, and Devices
  • Java SE, Client Side Technologies, and Rich User Experiences
  • The Java Frontier

Last years impressions
I compiled some picture impressions from last years JavaOne. It was nice. If you like to see more, take a look at the flickr.com/myfear photo set .

Resources and Information
The Aquarium
JavaOne Conference Blog
JavaOne Website
Oracle Mix

Wednesday, April 20, 2011

New Article in Java Tech Journal: GlassFish 3.1: What's New and Hot

11:39 Wednesday, April 20, 2011 Posted by Test No comments:
Just a short notice. You can find a new article of mine in the latest Java Tech Journal (former JAXmag) issue. In last month's Java EE 6-centric issue of Java Tech Journal, we looked at in-container testing for Java EE, with the Arquillian test framework; building RESTful Web Services in Java using JAX-RS; and were introduced to Java EE 6 compatible web profile servers, such as Siwpas. But, Java EE 6 marked a big step forward for the platform and there's still plenty of new technologies to cover in this second JTJ issue dedicated to all things Java EE 6!

The big news in the Java EE 6 ecosystem is, of course, the release of GlassFish 3.1, which is both the first major update to the platform since the debut of the 3.0 series and the first major release of GlassFish under Oracle. How does GlassFish 3.1 compare to the community roadmap presented by Oracle in March, 2010? Check out our 'GlassFish 3.1: What's New and Hot' article to find out!
Get it: It's for free!

Tuesday, April 19, 2011

GlassFish 3.1 with Oracle Coherence for Java Version 3.7

07:56 Tuesday, April 19, 2011 Posted by Test No comments:
Yesterday, Oracle released the latest evolution of Coherence, their flagship, distributed in-memory data grid product Oracle Coherence 3.7. Coherence 3.7 simplifies the configuration and management of large-scale deployments and provides more data storage capabilities and intelligent and dynamic load balancing of client connections. The new Elastic Data feature introduces breakthrough technology that enables the use of both memory and disk-based devices for data grid storage, enabling near memory speed access to data, regardless of storage medium, and greater flexibility in capacity and resource planning.
It also introduces dynamic load balancing and automatic proxy discovery for Coherence*Extend clients (for example, application servers or desktop applications accessing the Oracle Coherence data grid). It also integrates with F5 BIG-IP Load Traffic Manager (LTM) and SSL Acceleration technologies to take advantage of existing infrastructures to secure, optimize and load balance application traffic. Coherence configuration files are now described using XML schema definitions (XSD) and are no longer described using Document Type Definition (DTD).
Last but not least Coherence 3.7 finally introduces the native integration with GlassFish Server by using the Coherence*Web SPI for GlassFish (ActiveCache for GlassFish), providing "no code change" installation and configuration of Coherence*Web, making it dramatically easier for GlassFish Server users to scale their applications. And that's exactly what we are going to do today.

Get the latest Oracle GlassFish Server 3.1. Unzip/install it to your favorite location. Download Oracle Coherence for Java Version 3.7. Same here: Unzip to your favorite location. Open the coherence_3.7\lib\webInstaller.jar and extract the webInstaller.jar\web-install\coherence-web.jar and the session-cache-config.xml. Now you have to create a domain if you haven't already (asadmin create-domain coherenceTest). Copy the coherence.jar from coherence_3.7\lib\ to your domain\lib folder.

If you are starting from scratch, you have to fire up your favorite IDE and create a new Web or Ear Project. If you are configuring a web project, copy the coherence-web.jar file to the /WEB-INF/lib/ directory of your Web application. If you are configuring an ear project, copy the coherence-web.jar file to the EAR file's /lib. The session-cache-config.xml needs to be in your /WEB-INF/classes folder.
For this simple example I refer to the good old clusterjsp (taken from Arun's Screencast #34). Extract it. Put coherence-web.jar into ear/lib folder and create a WEB-INF/classes folder in which you put the session-cache-config.xml file. Great. Delete the sun-web.xml from WEB-INF and create a new glassfish-web.xml containing:
<session-manager persistence-type="coherence-web" />
Done. Package everything up again.

Start a Cache Server
A Coherence data node (also known as a cache server) is responsible for storing and managing all cached data. It can be run either in a dedicated JVM (out-of-process) or within a GlassFish Server instance (in-process). The simplest setting is to run it in-process. To make this easy you have to edit the config/domain.xml and add a JVM Option:
Now fire up your GlassFish and deploy the sample. If you are looking at the server.log you see Oracle Coherence coming up and logging some fancy stuff:
Oracle Coherence Version Build 23397
 Grid Edition: Development mode
  Clustered Session Cache Name=session-storage
  Local Session Cache Name=local-session-storage
  Local Session Attribute Cache Name=local-attribute-storage
  Death Certificate Cache Name=session-death-certificates
  SessionDistributionController Class Name=com.tangosol.coherence.servlet.glassfish31.GlassFishHybridController
  AttributeScopeController Class Name=com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeController
That's good. Now you know, that everything is working.

Start your GlassFish and deploy the application
Now you can start the application and use it as normal. This doesn't make too much sense if you are running everything on one node only. You should try to configure a complete cluster with at least one node and two or even more instances to experience the session replication. This very basic example makes use of all the defaults present for Coherence*Web Cache and cluster configuration. If necessary, you can provide an alternate cache and cluster configuration in your own custom session-cache-config.xml and tangosol-coherence-override.xml file. You must include the file in the WEB-INF/classes. Please refer to the complete documentation (see links below) for details.

Links and Further Readings
High performance JPA with GlassFish and Coherence
Oracle® Coherence User's Guide for Oracle Coherence*Web
Installing Oracle Coherence for Java
Using Coherence*Web with GlassFish Server
Installing and Configuring Eclipse and OEPE with Coherence

The GlassFish Product Manager Adam Leftik published two screencasts about the concepts behind Oracle Coherence and how Active Cache for GlassFish provides seamless integration with Coherence*Web. This is great additional information if you need to know more about the whole topic.

Active Cache For GlassFish Part 1 of 2

Active Cache For GlassFish Part 2 of 2

Thursday, April 7, 2011

Running RichFaces 4.0.0.Final Showcase on WebLogic Server

06:42 Thursday, April 7, 2011 Posted by Test 4 comments:
A very short notice: RichFaces 4.0.0.Final is running smoothly on WebLogic server Need a brief howto? Here you are:
- Download RichFaces 4.0.0.Final distribution
- unzip to a suitable location
- navigate to \richfaces-4.0.0.Final\examples\richfaces-showcase
- edit the pom.xml and remove/uncomment the relativePath of the parent (<!-- <relativePath>../parent/pom.xml</relativePath> -->)
- add the jboss nexus repository

- Follow the instructions on my older post to deploy the jsf(2.0, library to WebLogic and create a weblogic.xml with the library link in src\main\webapp\WEB-INF.
- type mvn clean install -P jee6
- deploy the exploded or packaged war from \target to your WebLogic.
- Enjoy!

Tuesday, April 5, 2011

Test Coverage for your Enterprise Beans. Running Eclemma with GlassFish 3.1

12:22 Tuesday, April 5, 2011 Posted by Test 1 comment:
, , ,
Have you ever been struggling with the percentage of test coverage in your projects? It's essential for all development projects to not only have a good feeling about your overall test coverage but to have some tool at hand to resilient number at hand for each iteration you do.
If you are working with Java EE projects, you have to find a way to check coverage for your container managed beans. This is a short howto about using Eclemma with Eclipse and GlassFish Embedded Container to get coverage information about your EJBs.

Get yourself a recent Eclipse Helios build (I am using the Eclipse IDE for Java EE Developers) and install any additional components (e.g. m2eclipse, GlassFish server adapters) you may need. Don't forget to get a recent GlassFish Server 3.1 Open Source Edition install (Full Platform). I'm going to demonstrate the usage of the Embedded Container in two different ways, so you should have Maven at hand, too. Last step is to install Eclemma into your Eclipse version.

What's all this stuff around?
If you start googling about embedded EJB glassfish and so on, you get a couple of solutions out there. Some mention the EJB 3.1 container API, some the embedded GlassFish, some talk about the Embedded Maven Plugin. So the very first thing I'd like to do is to tell you about the options you have to run your enterprise beans in embedded mode.

GlassFish Server 3.1 Embedded Server
The complete GlassFish server has a embeddable API. These is falling into different catagories. Top level APIs (org.glassfish.embeddable) which provide classes and interfaces necessary to embed GlassFish and perform lifecycle operations, application deployments and runtime configurations. Scattered Archive APIs (org.glassfish.embeddable.archive) which contain an abstraction for a scattered Java EE archive. The Web Container APIs (org.glassfish.embebdable.web, org.glassfish.embeddable.web.config) which provide classes and interfaces necessary to programmatically configure embedded WebContainer and create contexts, virtual servers, and web listeners. The advanced pluggability or Service Provider Interfaces (org.glassfish.embeddable.spi) to plugin a custom GlassFish runtime. The last part is the EJB container APIs (javax.ejb.embeddable) which are part of the EJB 3.1 Specification, Embeddable Container Bootstrapping. All those APIs help you to completely integrate a GlassFish server into your own infrastructure. If you are willing to use the complete embedded Server you have to add either the full- or the web-profile jars to your project.


EJB 3.1 container API
Starting with Java EE 6 and EJB 3.1 you have the new API for running your beans outside the container (GlassFish 3.1 docs). The EJB 3.1 Embeddable API supports all EJB 3.1 Lite features with addition of the EJB timer service and testing of EJB modules packaged in a WAR file. For EJB modules in a WAR file (or an exploded directory), if a web application has one EJB module, and there are no other EJB modules in the classpath, those entries (libraries) are ignored. If there are other EJB modules, a temporary EAR file is created. For EJB modules in a WAR file to be tested, the client code must use EJB modules with interfaces or without annotations. Those EJB modules are not part of the classpath and can't be loaded by the client class loader. This API is mostly valuable for outside container testing of your EJBs. If you are willing to use this container API only, you simply have to add the %AS-INSTALL%/glassfish/lib/embedded/glassfish-embedded-static-shell.jar from your existing (!) GlassFish installation to your project.

The Maven GlassFish Plugin
The Maven Glassfish Plugin is a Maven2 plugin allowing management of Glassfish domains and component deployments from within the Maven build lifecycle. It encapsulates domain configuration and deployment attributes within the build configuration for a more rapid development integration loop and simplified management of continuous integration testing of components destined for deployment within the Glassfish V2 and later JavaEE containers. As far as I know, this plugin simply facilitates the available asadmin commands to control a GlassFish server installation.

Getting started with Maven and the GlassFish Server 3.1 Embedded Server API
In this first step, I am going to demonstrate the usage of the embedded Server API. Create a new maven ejb module project and add the full-profile dependency to it:


Implement a simple ServiceBean with some methods. It should be more than one, because I would love you to see some not covered methods, too ;)

// ... imports
public class SimpleService {
// ...
public String saySomething(String sometext) {
LOGGER.log(Level.INFO, "sometext: {0}", sometext);
return "hello from " + sometext;

Now implement your Testclass. Let's call it SimpleServiceTest. The real magic happens in @BeforeClass and @AfterClass.

// ... imports
public static void setUpBeforeClass() throws Exception {
// Define GlassFish and add target/classes as deploy folder
GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish();
Deployer deployer = glassfish.getDeployer();
URI uri = new File("target/classes").toURI();

public static void tearDownAfterClass() throws Exception {
// Stop GlassFish

The only thing left to do is to actually implement your test.

public void testSaySomething() {
try {
InitialContext ic = new InitialContext();
SayHelloBean simpleService = (SayHelloBean) ic
String response = simpleService.saySomething("Markus");
assertEquals("hello from Markus", response);
} catch (NamingException e) {
throw new AssertionError(e);

Remember to use the appropriate JNDI name. Every EJB that could be found is deployed to the embedded server and the JNDI name is built using java:global/classes as prefix followed by the simple class name of the EJB (you can also use the appropriate Global JNDI name as in the above example). If you now run your test with "Coverage As ... > JUnit Test (Alt + Shift + E,T)" you get a new Coverage view in Eclipse which shows something like this:

Your code gets highlighted according to the coverage report also:
Great! You are done. Happy coding. Now let's look at the next option.

Getting started with ANT and the EJB 3.1 container API
Create a new EJB Project with eclipse and add the %AS-INSTALL%/glassfish/lib/embedded/glassfish-embedded-static-shell.jar to your build path. Don't forget to remove the Server Runtime you assigned during project creation. Again: Create your EJB(s), and a Testcase. And again, the real magic happens in @BeforeClass and @AfterClass.

// ... imports

private static EJBContainer ejbContainer;

public static void setUpBeforeClass() throws Exception {
Map properties = new HashMap();
properties.put(EJBContainer.MODULES, new File("target/classes"));
ejbContainer = EJBContainer.createEJBContainer(properties);

public static void tearDownAfterClass() throws Exception {

After that you have to do your test implementation, which is in fact very similar to the above example:

public void testSaySomething() {
try {
InitialContext ctx = new InitialContext();
SayHelloBean simpleService = (SayHelloBean) ctx .lookup("java:global/classes/SayHelloBean!net.eisele.coverage.ejb.SayHelloBean");
String response = simpleService.sayHello("Markus");
assertEquals("Hello: Markus", response);
} catch (NamingException e) {
throw new AssertionError(e);

If you now run your JUnit test "Run As ... > JUnit Test (Alt + Shift + X,T) everything works fine. Running this with Eclemma Coverage doesn't work. You get a nasty javax.naming.NamingException because the lookup failed. If you scan the console output you see, that the EJBs are bound to some very strange names:


To prevent this, you have to change the Coverage configuration for your test to "In-place instrumentation".

EclEmma tries not to touch your project's content. Therefore class files are normally instrumented outside your project in a temporary folder. This is exactly where the fancy JNDI names come from. In-place instrumentation will modify your class files. Instrumented class files can not be used with launch modes other than Coverage. Therefore a clean build is required after a coverage launch with in-place instrumentation.
Beside this change, everything works exactly the same way as with the maven example.

It works. Even if it is a very strange and violent thing to do. You could instrument your classes with additional coverage information and you could also test them with your embedded GlassFish. Hope this little introduction was helpful.

Links and Readings
Using the EJBContainer API with or without Maven (but with GlassFish v3)
Unit Testing EJBs and JPA with Embeddable GlassFish
GlassFish >>Embedded
Quick introduction to Embeddability of GlassFish Open Source Edition 3.1
Overview of the GlassFish Embedded APIs (JavaDoc)
Further Source Examples of using GF Embedded (java.net svn)
Changing Log Levels in Embedded GlassFish