Monthly Archives: June 2010

The Java Project with JAXB 2.2 via NetBeans 6.8

I’ve found some exception during testing the Java project with JAXB 2.2 via NetBeans 6.8 as

java.lang.NoClassDefFoundError: 6/8\ide12\modules\ext\jaxb\api

Caused by: java.lang.ClassNotFoundException: 6.8\ide12\modules\ext\jaxb\api

at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

at java.lang.ClassLoader.loadClass(ClassLoader.java:303)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)

Could not find the main class: 6.8\ide12\modules\ext\jaxb\api. Program will exit.

Exception in thread “main” Java Result: 1

I had searched via Google and found the solution as following: –

1. Please right click at your Java project and choose “Properties”. The system will show you a “Project Properties” window.

2. Within that window, “Categories” panel, Choose the node named “Run”.

3. You will see the “VM Options:” at the right area, which mentions as

-Djava.endorsed.dirs=${jaxbwiz.endorsed.dirs}

4. Please remove this value from your project.

I would like to thank to a very smart guy here

The EJB Session Bean Unit Testing with JUnit (Extended)

Even the Glassfish Application Server is not to be started and your application also is not to be deployed. You should firstly configure the other required resources, the connection pool for example, by using the Glassfish Application Server Administration console since the configuration is shared between the Glassfish Application Server and EJB embedded container. If not you may face some trouble about the resources missing/absence exception.

Updated on June 29, 2010
My fault. The application should be deployed to the Glassfish Application Server once before running the unit testing. If not you will face some trouble about the JNDI looking up.

The EJB Session Bean Unit Testing with JUnit

The EJB embedded container is introduced by the Glassfish Application Server version 3 and it is a core part for unit testing. It’s light weight and strong enough so that the EJB unit testing can be executed without the starting of Glassfish Application Server. For sure, you may imagine it can be applied for other purpose as same as the embedded database.

Via NetBean, you can create the JUnit test case and test suit simply by right clicking at the node named “Test Packages” of your EJB project and choose the one you want. The following is the simply step for initiating the EJB embedded container: –

Creating the JUnit test case or test suit

1. Declare and initiate the EJB embedded container.

private static EJBContainer ejbContainer = EJBContainer.createEJBContainer();

2. Declare and initiate the JNDI context for looking up the EJB.

private static Context context = ejbContainer.getContext();

3. Simply use the context object for looking up your EJB and another JavaEE resources via JNDI, for example, The connection pool, the EJB and so on.

4. The rest is creating your test respectively to you business, unit or others test case by following the JUnit standard.

Note:

1. The EJBContainer is javax.ejb.embeddable.EJBContainer

2. The Context is javax.naming.Context

Executing the test case with the EJB embedded container

The prerequisite

1. The EJB application is not required to be deployed to the Glassfish Application Server

2. The Glassfish Application Server must not be started since the ports will be clashed since the embedded will share the same ports.

The execution

Just simply right click at your test case or test suit and choose “Run File”.

The EJB Session Bean as a Business Services

I still keep following my integrating concept by treating every single integrated point as an interface. This business services is not an exception. I treat it like a main program for each public services. It also integrates to among of the lower layer, the EJB Session Bean which wraps the JPA Entity with purpose to hide the complexity and difficulty from the caller. It is one and only one who know the complexity of its JPA Entity, including with its business logic.

Since it is the business services which is published as a public accessing remotely by among of others, The interface should be annotated as @Remote to ensure the remote accessing. Again I also create an abstract POJO which implements that interface and wraps the common activities. The business services session bean will be derived from this abstract class and it is annotated as @Stateless

Note:

@Remote is an annotation for the interface and declaring it to be accessed remotely.

@Stateless is annotation for the POJO and declaring it to be a stateless session bean.

The EJB Session Bean for wrapping the JPA Entity

My expectation is generating the JPA Entity by using the NetBeans or other tools. It does not suppose to be modified by hand. If there is any changing at the database layer, I will regenerate it.

I decide to create a EJB Session Bean for wrapping the basic functions for integrating with the JPA Entity, The set of Create, Read, Update , Delete (CRUD) functions, especially the variety of finding function. I hope it may help to increase the transparent JPA Entity changing. I treat this session bean as an interface for any required integrating by the other through the JPA entity, as long as there is no interface changing, there is also no the client changing, too.

Furthermore, this session bean should be accessed locally, since the other should not know how to manage this JPA entity. The difficulty and complexity should be hidden by wrapping as a business services, note I will update about it later.

I create the interface by annotating it as @Local to ensure the local accessing. The good news is the session bean can be derived from any POJO. I also wrap the common activity to the abstract class which implements that interface. The wrapping session bean will be derived from this abstract class and it is annotated as @Stateless

Note:

@Local is an annotation for the interface and declaring it to be accessed locally.

@Stateless is annotation for the POJO and declaring it to be a stateless session bean.

%d bloggers like this: