Home/ Questions/Q 1074993
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T21:12:43+00:00

I’m using NetBeans and GlassFish 3.0.1 to create an EJB3 application. I have written

  • 0

I’m using NetBeans and GlassFish 3.0.1 to create an EJB3 application. I have written a few Unit Tests, which get run via JUnit and make use of the embedded GlassFish. Whenever I run these tests on my development machine (so from within NetBeans), it’s all good.

Now I would like to let Hudson do those tests. At the moment it is failing with lookup failure on a resource (in this case the datasource to a JPA persistance unit):

[junit] SEVERE: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
[junit] java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'mvs_devel' in SerialContext

After searching around and trying to learn about this, I believe it is related to the embedded GlassFish not having been configured with resources. In other words it’s missing a domain.xml file. Right?

Two questions:

  1. Why does it work with NetBeans on my dev box? What magic does NetBeans do in the background?
  2. How should I provide the file? Where does the embedded GlassFish on the Hudson-box expect it?

Hudson is using the same Ant build-scripts (created by NetBeans).

I’ve read this post about instanceRoot and the EmbeddedFileSystemBuilder, but I don’t understand enough of that. Is this needed for every TestCase (Emb. GF gets started/stopped for each bean-under-test)? Is this part of EJBContainer.createEJBContainer()? Again, why is it not necessary to do this when running tests on NetBeans?

Update
Following Peter’s advice I can confirm: when running ant on a freshly checked out copy of the code, with the same properties as hudson is configured, the tests get executed!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    10-1 it is a classpath issue as IDE’s tend to swap paths in and out depending if you run normally or unittests.

    Try running the tests on a commandline from a freshly checked out version from your SCM. Chances are you’ll have the same error. Debugging on your local machine is a lot easier than on a remote machine.

    When it builds reliably on the command line (in a separate directory) then it is time to move to hudson.

    • 0