Sunday 9 October 2011

Different Ways to use JPQL

Introduction

There are several ways in which to execute JPQL (Java Persistence Query Language). I'll introduce the "old way" first, with JDBC and direct connections to the database, before branching off into the ways used by ORMs (Object Relational Mapping).

Each way has its advantages and disadvantages.

The old way:
  • direct database access
  • database connection pool
Using an ORM
  • hql in java code
  • named queries in annotations
  • named queries in xml
  • Criterion API
  • retrieving the object by its primary key

The Old Way

Direct Database Access

This is an example of direct database connection with jdbc. Setting it up, sending the query, reading the result, close the resultset and shutting down the connection.


/**
 * Connects to the database using an url. The url looks something like
 * "jdbc:mysql://localhost.localdomain/mud?user=root&password=". Uses the
 * classname in Constants.dbjdbcclass to get the right class for interfacing
 * with the database server. If the database used is changed (or to be more
 * specific the jdbc driver is changed) change the constant.
 * 
 * @throws InstantiationException
 *             happens when it is impossible to instantiate the proper
 *             database class, from the class name as provided by
 *             Constants.dbjdbcclass.
 * @throws ClassNotFoundException
 *             happens when it is impossible to find the proper database
 *             class, from the class name as provided by
 *             Constants.dbjdbcclass.
 * @throws IllegalAccessException
 *             happens when it is not possible to create the database class
 *             because access restrictions apply.
 * @throws SQLException
 *             happens when a connection to the database Server could not be
 *             established.
 */

public Macro runQuery() throws SQLException, InstantiationException,
    ClassNotFoundException, IllegalAccessException
{
  Macro result = null;
  try
  {
    Class.forName(Constants.dbjdbcclass).newInstance();

    // jdbc:mysql://[host][,failoverhost...][:port]/[database]
    // [?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
    String theUrl = Constants.dburl + "://" + Constants.dbhost
      + Constants.dbdomain + "/" + Constants.dbname + "?user="
      + Constants.dbuser + "&password=" + Constants.dbpasswd;
    theConnection = DriverManager.getConnection(theUrl);

    PreparedStatement statGetMacro = null;
    statGetMacro = theConnection.prepareStatement(sqlGetMacro);
    statGetMacro.setString(2, macroname);
    res = statGetMacro.executeQuery();
    if (res != null && res.next())
    {
      result = new Macro(res.getString("macroname"), res.getString("contents"));
      res.close();
    }
    statGetMacro.close();
  } catch (Exception e)
  {
    throw new MudDatabaseException(Constants.DATABASECONNECTIONERROR, e2);
  }
  finally
  {
    if (theConnection != null) {theConnection.close();}
  }
  return result;
}
Advantages:
  • complete control
  • very little libraries required
Disadvantages:
  • sql syntax spread throughout the java code
  • lots of error-prone boiler plate code required
  • expensive in setting up new database connections for every query
  • sytax of query not checked, until method called
  • changing the query requires source code change, recompilation, repackaging, etc

Database Connection Pool

This is example of database connection with jndi resource pool, where the only thing required is the jndi name. In this case it is irrelevant which connection we receive from the connection pool. The actual theConnection.close() does nothing, but returns the connection back to the pool.


public void runQuery() throws Exception
{
  Connection con=null;
  ResultSet rst=null;
  PreparedStatement stmt=null;

  try
  {
    Context ctx = new InitialContext();
    DataSource ds = (DataSource) ctx.lookup("jdbc/mmud");
    con = ds.getConnection();

    stmt=con.prepareStatement("select * from links where type = 1 order by creation");
    rst=stmt.executeQuery();
    while(rst.next())
    {
        out.println("<li><A HREF=\"" + rst.getString("url") + "\">" +
          rst.getString("linkname") + "</A> (<i>" +
          rst.getString("name") + "</i>)<P>");
    }
    rst.close();
    stmt.close();
  }        
  finally
  {
    if (rst != null) {try {rst.close();} catch (Exception e){}}
    if (stmt != null) {try {stmt.close();} catch (Exception e)}}
    if (con != null) {try {con.close();} catch (Exception e){}}
  }
}

Advantages:
  • database connection resource pool
  • no need to open and close connection, connections are reused
Disadvantages:
  • sql syntax spread throughout the java code
  • still a lot of error-prone boiler plate code required
  • sytax of query not checked, until method called
  • if connections/resources not properly released, the pool will run out of connections/resources
  • changing the query requires source code change, recompilation, repackaging, etc

Using an ORM

hql in java code

@Override
public void deleteAddress() 
{
  StringBuilder queryBuilder = new StringBuilder();
  queryBuilder.append("DELETE Address address ");
  queryBuilder.append("WHERE  address.country = 'Italy' ");
  queryBuilder.append("AND NOT EXISTS (SELECT '' ");
  queryBuilder.append("            FROM Customer cust ");
  queryBuilder.append("            WHERE cust.address = address ");
  queryBuilder.append("           ) ");

  Query query = em.createQuery(queryBuilder.toString());
  query.executeUpdate();
}

Unfortunately, the code above is what I encounter frequently in the source of my employers current software product.

Advantages:
  • none
Disadvantages:
  • a StringBuffer is created every time the method is called, at the very least this should be a constant
  • jpql is created and parsed and compiled every time the method is called
  • sql/hql/jpql syntax spread throughout the java code
  • sytax of query not checked, until method called
  • changing the query requires source code change, recompilation, repackaging, etc


Named queries in annotations

Queries can be defined in the annotations on top of Entity classes. The annotation would look a little like the one below.

@NamedQueries({
    @NamedQuery(name = "Character.findAll", query = "SELECT c FROM Character c"),
    @NamedQuery(name = "Character.findByName", query = "SELECT c FROM Character c WHERE c.name = :name")})

One of the problems often heard is that the annotation has to be on an Entity class, when you perhaps would prefer to have it someplace else. In that case, it might be an idea to define the constants as strings in a different part, like a Service or a DAO or what have you, and refer to them in the NamedQuery annotations. Like in the two-part example below.

As the name of a named query is global within the persistent provider, it is essential to create unique names within the application. That is why in most cases, the name of a named query is prefixed with the class name.

/**
 * Game bean.
 * @author Mr. Bear
 */

@Stateless
@Remote(GameBeanRemote.class)
public class GameBean implements GameBeanRemote
{
    public static final String character = "Character";

    /**
     * label for the find all characters query.
     */

    public static final String FINDALLCHARS_QUERYNAME = character + ".findAll";

    /**
     * query for the find of all characters query.
     */

    public static final String FINDALLCHARS_QUERY = "SELECT c FROM Character c";

    /**
     * label for the find character based on name query.
     */

    public static final String FINDCHAR_QUERYNAME = character + ".findByName";

    /**
     * query for the find of character based on name query.
     */

    public static final String FINDCHAR_QUERY = "SELECT c FROM Character c WHERE c.name = :name";

    @PersistenceContext(unitName = "datasource")
    private EntityManager em;
/**
 * The Character entity.
 * @author Mr. Bear
 */

@Entity
@Table(name = "mm_usertable")
@NamedQueries({
   @NamedQuery(name = GameBean.FINDALLCHARS_QUERYNAME, query = GameBean.FINDALLCHARS_QUERY),
   @NamedQuery(name = GameBean.FINDCHAR_QUERYNAME, query = GameBean.FINDCHAR_QUERY)})
public class Character implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @Basic(optional = false)
    @NotNull
    @Size(min = 1, max = 20)
    @Column(name = "name")
    private String name;

Using the named queries in code is as simple as getting the entity manager and telling him the name of the NamedQuery you wish to use, add the parameter values, and request the result. You can refer to the NamedQueries by name, hence the name, get it?

@Override
public CommandOutput retrieveCharacter(String name)
{
    itsLog.entering(this.getClass().getName(), "retrieveCharacter");
    Query q = em.createNamedQuery("Character.findByName", Character.class);
    q.setParameter("name", name);
    Character c = (Character) q.getSingleResult();
    if (c == null)
    {
        itsLog.exiting(this.getClass().getName(), "retrieveCharacter");
        return new CommandOutput("""""");
    }
    CommandOutput co = new CommandOutput(c.getName(), c.getArm(), c.getBeard());
    itsLog.exiting(this.getClass().getName(), "retrieveCharacter ", co);
    return co;
}

The great part of NamedQueries is that they are checked and pre-compiled by Hibernate when the server starts, so you get instant messages if you screwed up the syntax.

Advantages:
  • the Persistence provider might be able to precompile them, and this can help catch bugs before deployment
  • sql syntax no longer spread throughout the java code
  • sql queries externalised to the java code
  • there's a central place for queries, making them easy to find and easy to re-use.
Disadvantages:
  • named queries in annotations can only be added to the Entity classes or the SuperMapClass. This is especially awkward when you have a query spanning multiple entities.
  • named queries are referenced using a key, which is global to the application.
  • named queries are a little difficult to debug, as a change requires an application server reboot.
  • changing the query in the annotation requires source code change, recompilation, repackaging, etc

In the examples below, JBoss is used in combination with Hibernate. The first example is the jboss log when things go wrong, and the second example is when things go right.

09:19:23,635 ERROR [SessionFactoryImpl] Error in named query: FullAddress.findAddressesOfCustomers
org.hibernate.QueryException: could not resolve property: entitynr of: mrbear.entity.Address [DELETE Address address WHERE address.country = 'Italy' AND address.entitynr > 1000 AND NOT EXISTS (SELECT '' FROM Customer cust WHERE cust.address = address) ]
at org.hibernate.persister.entity.AbstractPropertyMapping.propertyException(AbstractPropertyMapping.java:67)
09:23:10,946 INFO [AnnotationBinder] Binding entity from annotated class: mrbear.entity.Address
09:23:10,948 INFO [QueryBinder] Binding Named query: FullAddress.findAddressesOfCustomers => DELETE Address address WHERE address.country = 'Italy' AND address.entityNr > 1000 AND NOT EXISTS (SELECT '' FROM Customer cust WHERE cust.address = address)

Let me point you especially to the fact that HQL (or JPQL for that matter), contrary to SQL, is case-sensitive (for the most part). It would have to be, as it has a direct link to java classes and these are also case-sensitive.

In the example above, the getter and setter for entity number was specified as getEntityNr and setEntityNr, hence the problem with the casing in the first example.

According to Gavin King [1]:
We leave it up to you if you want to utilize the named query feature. However, we consider query strings in the application code (except if they're in annotations) to be the second choice; you should always externalize query strings if possible.

Named queries in xml

If you do not like to have your JPQL in your code at all, there is always the possibility of putting the queries into the xml files that are a part of the configuration of the jar file.

There is no reason why you cannot have both, both named queries in your annotations and queries in your xml persistence configuration files.

One of the great things is that the named queries in the persistence xml files take precedence over the named queries in the annotations. This means, that, when deployed in a specific production environment, it is possible to change the named queries, without having to touch/recompile/build/package the java source code. So, you can do convention over configuration.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="mmud" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>mmud</jta-data-source>
    <!-- Named JPQL queries per entity, but any other organization is possible  -->
    <mapping-file>META-INF/jpql/Character.xml</mapping-file>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties/>
  </persistence-unit>
</persistence>
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings version="1.0" xmlns="http://java.sun.com/xml/ns/persistence/orm"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd "
>

    <named-query name="Character.findByName">
        <query>
            SELECT
                c
            FROM
                Character c
            WHERE
                c.password = :name
            OR
                c.name = 'Midevia'
        </query>
    </named-query>
</entity-mappings>

So in the code example that uses annotations, when using these two persistence xml files displayed above, suddenly "Midevia" is retrieved from the database, instead of the name you requested.

Advantages:
  • the Persistence provider might be able to precompile them, and this can help catch bugs before deployment
  • sql syntax no longer anywhere in the java code
  • there's a central place for queries, making them easy to find and easy to re-use.
  • named queries can be spread through many different xml files, making them more easy to categorise.
Disadvantages:
  • named queries are referenced using a key, which is global to the application.
  • named queries in xml, can be changed, if you don't mind hacking your way through xml.
  • named queries are a little difficult to debug, as a change requires an application server reboot.

Criterion API

@Override
public CommandOutput retrieveCharacter(String name)
{
    itsLog.entering(this.getClass().getName(), "retrieveCharacter");

    // setup criteria builders/queries
    CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
    CriteriaQuery criteriaQuery = criteriaBuilder.createQuery();

    // add from
    Root<Character> from = criteriaQuery.from(Character.class);
    CriteriaQuery<Character> select = criteriaQuery.select(from);

    // add predicate
    Predicate predicate = criteriaBuilder.equal(from.get("name"), name);
    criteriaQuery.where(predicate);

    // create the select query
    TypedQuery<Character> typedQuery = em.createQuery(select);

    // get the results
    List<Character> resultList = typedQuery.getResultList();

    if (resultList == null || resultList.size() != 1)
    {
       itsLog.exiting(this.getClass().getName(), "retrieveCharacter");
       return new CommandOutput("""""");
    }
    CommandOutput co = new CommandOutput(
            resultList.get(0).getName(),
            resultList.get(0).getArm(),
            resultList.get(0).getBeard());
    itsLog.exiting(this.getClass().getName(), "retrieveCharacter ", co);
    return co;
}
Advantages:
  • the Persistence provider might be able to precompile them, and this can help catch bugs before deployment
  • sql syntax no longer anywhere in the java code
  • the query is dynamic, making it easy to change depending on input from the user
  • it is java, so every tool and compiler can aid in the development, like syntax checking and type checking and the like
Disadvantages:
  • fairly unreadable

Retrieving the object by its primary key

Ideally, we do not wish to use SQL or HQL or the Criteria API at all. If possible, we just want to tell the Entity Manager to get the objects we need. In most cases, this is not easy. But for some concepts, like getting an object based on its primary key (so we are always sure there's just one (or zero) available) there's a much more straightforward way.

@Override
public CommandOutput retrieveCharacter(String name)
{
    itsLog.entering(this.getClass().getName(), "retrieveCharacter");
    Character c = em.find(Character.class, name);
    if (c == null)
    {
        itsLog.exiting(this.getClass().getName(), "retrieveCharacter");
        return new CommandOutput("""""");
    }
    CommandOutput co = new CommandOutput(c.getName(), c.getArm(), c.getBeard());
    itsLog.exiting(this.getClass().getName(), "retrieveCharacter ", co);
    return co;
}
Advantages:
  • no SQL/HQL/JPSQL of any kind required
  • the JPA implementation can cache the object and retrieve is quickly.
Disadvantages:
  • only for specific uses, like retrieving objects by primary key.

Conclusion

I hope to have demonstrated the different uses that exist in retrieving data from a database using any kind of ORM, compatible with the JPA. As you are no doubt aware from this piece, I strongly consider the last four examples to be good practices of creating JPQL queries in your application.

As always, each has its strong and weak points, and therefore are applicable to different situations. Evaluate the situation and pick the one that is best suited for the job.

References


[1] Java Persistence with Hibernate
Christian Bauer, Gavin King
[2] chapter 2.3 - Hibernate Community Documentation
http://docs.jboss.org/hibernate/annotations/3.5/reference/en/html_single/
[3] Organize Your Named JPQL Queries
http://eubauer.de/kingsware/2011/03/25/organize-your-named-jpql-queries/
[4] Hibernate: Criteria vs. HQL
http://stackoverflow.com/questions/197474/hibernate-criteria-vs-hql
[5] Are Hibernate named HQL queries (in annotations) optimised?
http://stackoverflow.com/questions/2641997/are-hibernate-named-hql-queries-in-annotations-optimised
[6] GlassFish Project - Java Persistence Example
http://glassfish.java.net/javaee5/persistence/persistence-example.html
[7] Use string constants in annotations
http://javahowto.blogspot.com/2009/04/use-string-constants-in-annotations.html
[8] Java Persistence 2.0 Public Draft: Criteria API
http://blogs.oracle.com/ldemichiel/entry/java_persistence_2_0_public1
[9] Dynamic, typesafe queries in JPA 2.0
http://www.ibm.com/developerworks/java/library/j-typesafejpa/
[10] Where to put named queries in JPA?
http://jdevelopment.nl/put-named-queries-jpa/
[11] Java Glossary
http://randomthoughtsonjavaprogramming.blogspot.com/p/glossary.html

Wednesday 5 October 2011

Constructor in Anonymous Inner Class

Recently, I've been playing with JMockit, and I've come across certain language constructs in java that confused me.

It appears they were related to creating a different body for a constructor in the inner anonymous class. Which is hard to do, as the name of the Anonymous Inner Class is unknown.

package mrbean.anonymous;

public class Anonymous 
{

  private int i = 5;

  public int getI() 
  {
    System.out.println(this + " getI");
    return i;
  }

  public void setI(int i) 
  {
    System.out.println(this + " setI");
    this.i = i;
  }

  public Anonymous() 
  {
    System.out.println(this + " Constructor");
  }

  public void doStuff() 
  {
    System.out.println(this + " doStuff");
    System.out.println("i=" + new Anonymous() {
      {
        System.out.println(this + " Anonymous Constructor");
        setI(10);
      }
    }.getI());
  }

  /**
   * Main method to start the program.
   * @param args arguments
   */

  public static void main(String[] args) 
  {
    System.out.println("main: Start program.");
    Anonymous first = new Anonymous();
    System.out.println("main: i=" + first.getI());
    first.doStuff();
    System.out.println("main: End program.");
  }

}

This provided me with the following output:

main: Start program.
mrbear.anonymous.Anonymous@7d8a992f Constructor
mrbear.anonymous.Anonymous@7d8a992f getI
main: i=5
mrbear.anonymous.Anonymous@7d8a992f doStuff
mrbear.anonymous.Anonymous$1@23fc4bec Constructor
mrbear.anonymous.Anonymous$1@23fc4bec Anonymous Constructor
mrbear.anonymous.Anonymous$1@23fc4bec setI
mrbear.anonymous.Anonymous$1@23fc4bec getI
i=10
main: End program.

Especially in the creation of Expectations and Verifications in test methods in JMockit, it's quite common.

Saturday 1 October 2011

Creating Hello World in Netbeans IDE 7.0.1 and Glassfish 3.1

A simple attempt of mine to create a HelloWorld Enterprise JavaBean (EJB) in Netbeans 7.0.1. and Glassfish 3.1.

Primary use is for me to remember how to do this, and what needs to be configured to make it work.

Creating the JEE Application

First, start up your brand new Netbeans 7.0.1. and select a new project.

Select Java Enterprise Applications.





It will start creating the new project. You will end up with three new projects.


First of the projects, HelloWorldEE is the EAR file, which is a jar-file that is to be deployed to the glassfish server. It consists of two jar-files, that are created by the other two projects.

Second is HelloWorldEE-ejb, the project that is to contain our new Enterprise Java Beans (EJB).

Third is HelloWorldEE-war, the project that is to contain all the web stuff, like jsp pages, servlets, and what have you.

Let's create our first Enterprise Java Bean.



Here I've selected a Local interface for now. You'll notice two java files are generated, one containing the local interface and one containing the implementation.

We will add a business method.




Change the helloWorld method to return the string "Hello, world.". Now, in order to test it, we are going to create a java client that connects to the bean using Corba. However, for this to work, the interfaces need to be Remote, and not Local. Change the source code accordingly.

Your source code should look something like this:

package mrbear.beans;

import javax.ejb.Remote;

/**
 * The remote interface to my bean.
 * @author Mr. Bear
 */

@Remote
public interface MyFirstBeanRemote {

    /**
     * Returns the string "Hello, world."
     * @return String with text.
     */

    public String helloWorld();
    
}
package mrbear.beans;

import javax.ejb.Stateless;

/**
 * My first enterprise java bean.
 * @author Mr. Bear
 */

@Stateless
public class MyFirstBean implements MyFirstBeanRemote {

    @Override
    public String helloWorld() {
        return "Hello, world.";
    }

}

In the war project, a jsp page is automatically generated upon creation of the project, and it will help to check if the ear file was successfully deployed.

Try and "run" the project HelloWorldEE. A GlassFish 3.1 server will be started by Netbeans, the ear file deployed, and a webpage will be visible at url http://localhost:8080/HelloWorldEE-war/. It should show "Hello world!". Now, make no mistake! This is not our bean! This is the jsp page that is generated automatically in the war project. It shows that at least the ear file was successfully deployed.

The jsp file can be found at HelloWorldEE/HelloWorldEE-war/web/index.jsp

In your output window (HelloWorldEE(run)), you should see something like this:

Starting GlassFish Server 3.x
GlassFish Server 3.x is running.
Initial deploying HelloWorldEE to /home/mrbear/NetBeansProjects/HelloWorldEE/dist/gfdeploy/HelloWorldEE
Completed initial distribution of HelloWorldEE
Initializing...
Browsing: http://localhost:8080/HelloWorldEE-war

In the GlassFish log, you should see something like this:

INFO: Portable JNDI names for EJB MyFirstBean : [java:global/HelloWorldEE/HelloWorldEE-ejb/MyFirstBean, java:global/HelloWorldEE/HelloWorldEE-ejb/MyFirstBean!mrbear.beans.MyFirstBeanRemote]
INFO: WEB0671: Loading application [HelloWorldEE#HelloWorldEE-war.war] at [HelloWorldEE-war]
INFO: HelloWorldEE was successfully deployed in 5,409 milliseconds.

Pay special attention to the JNDI names used for the EJB MyFirstBean. We'll need those to create our HelloWorld java client.

Your bean should now be alive and kicking! You can check this by browsing to the administration console of your Glassfish server at http://localhost:4848/.


Creating the Java Client

Time to create a new project. Create a new project, and select Enterprise Application Client.





You do need to add a dependency in the HelloWorldClient to the HelloWorldEE-ejb (which resides in the HelloWorldEE) by selecting "add Project" in the Compile tab of "Libraries" of the Helloworld java client project.


Your java client source code in the main method should look something like this:

package helloworldclient;

import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import mrbear.beans.MyFirstBeanRemote;

/**
 * The client for connecting to the MyFirstBean bean.
 * @author Mr. Bear
 */

public class Main {

    /**
     * Main method, called when executing this program.
     * @param args the command line arguments
     */

    public static void main(String[] args) {
        System.out.println("Starting...");

        System.out.println("Establishing connection to the bean...");
        MyFirstBeanRemote example;
        try {
            InitialContext initialContext = new InitialContext();

            // INFO: Portable JNDI names for EJB MyFirstBean : 
            // java:global/HelloWorldEE/HelloWorldEE-ejb/MyFirstBean
            example = (MyFirstBeanRemote) initialContext.lookup("java:global/HelloWorldEE/HelloWorldEE-ejb/MyFirstBean");
            System.out.println("Calling method on the bean...");
            System.out.println("     Result: " + example.helloWorld());
        } catch (NamingException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
            System.exit(1);
        }
        System.out.println("Exiting...");

    }

}

When executing said project (remember, the Glassfish is still running), you can see the following in the log of Glassfish:

INFO: ACDEPL103: Java Web Start services started for the app client HelloWorldClient (contextRoot: /HelloWorldClient)
INFO: HelloWorldClient was successfully deployed in 85 milliseconds.

And the log of your java client, should show the following indicating success:

Copying 1 file to /home/mrbear/NetBeansProjects/HelloWorldClient/dist
Copying 2 files to /home/mrbear/NetBeansProjects/HelloWorldClient/dist/HelloWorldClientClient
Warning: /home/mrbear/NetBeansProjects/HelloWorldClient/dist/gfdeploy/HelloWorldClient does not exist.
Starting...
Establishing connection to the bean...
Calling method on the bean...
Result: Hello, world.
Exiting...

Now this is just the basics, but it is always good to start from a simple example that works, and then branch out from there. Good luck!

I plan to keep this article updated with new versions of software that are issued, and with new expansions, like adding an ORM to your little bean.

Remarks

I've chosen for Netbeans 7.0.1, as there is an issue with automatic downloading of Glassfish 3.1 in Netbeans 6.9

In order for the java client to connect to the Glassfish when the Glassfish is not conveniently started by the Netbeans on your local machine, you need to change the settings used to connect to the remote host. This can be done programmatically using a Properties java hashmap thing, or you can use the dreaded jndi.properties file. I guess that last one could use a blog entry all on its own. [1]

I've not mentioned anything about setting up Glassfish on your local machine, as Netbeans basically does all that for you. You just need to select the little checkbox with "Download Glassfish" when creating a new Java EE Application Project.

It is a pleasure to work with Netbeans and Glassfish, basically because the two are nicely intertwined and setting up the environment is almost a point-and-click experience and speedily done. It makes it possible to spend more time developing and less time battling frameworks, fixing dependencies and installing jar-files.


Update


Ever since the coming of EJB 3.1, it is no longer necessary to have a WAR archive for your web related things, a JAR archive for your Enterprise Java Beans, and an EAR archive containing these two. If you are not interested in keeping these two strictly apart (in the name of modularization), you can just toss all your EJBs into the same WAR and deploy that WAR in EJB 3.1.

It simplifies life tremendously.

References


[1] How do I access a Remote EJB component from a stand-alone java client?
http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB