In this section we want to break the cycle of having to issue a heavyweight Maven build every time we want to run an IT test. We can do this by making JUnit tests "IDE-friendly". What I mean by that is ... allow the IDE environment to derive usable values without relying on system properties being passed in from failsafe. Failsafe won't be involved with running your JUnit tests within the IDE. That means you can either get the usable values thru reasonable defaults or through the use of filtered property files in the classpath. Looking up the JNDI name for a remote EJB provides an excellent example of both techniques.

To derive properties for the InitialContext -- we used filtered property files.

#jndi.properties
java.naming.factory.initial=${java.naming.factory.initial}
java.naming.factory.url.pkgs=${java.naming.factory.url.pkgs}
java.naming.provider.url=${java.naming.provider.url}
#java.naming.security.principal=${jndi.user}
#java.naming.security.credentials=${jndi.password}

That got expanded by our initial Maven build to contain the following. The Maven/Eclipse plugin (m2e) within Eclipse will continue to keep this up to date. It has a plugin the provides understanding of what the maven-resource-plugin would do outside of the IDE and re-creates that functionality within the IDE environment.

#jndi.properties
java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.factory.url.pkgs=
java.naming.provider.url=http-remoting://127.0.0.1:8080
#java.naming.security.principal=known
#java.naming.security.credentials=password1!

There is nothing magical about jndi.properties. We can add more properties to that file (not common) or create other property files (e.g., it.properties) to be filtered and made available to the IT test. However, our other option was to pass in a system property (-DpropertyName=value) using the failsafe configuration.

<plugin>

    <groupId>org.apache.maven.plugins</groupId>

    <artifactId>maven-failsafe-plugin</artifactId>

    <configuration>

        <systemPropertyVariables>

            <jndi.name.reservation>ejb:basicejb-ear/basicejb-ejb/ReservationEJB!org.myorg.basicejb.ejb.ReservationRemote</jndi.name.reservation>

        </systemPropertyVariables>

    </configuration>

</plugin>

Anticipating the system property might not always be available or necessary in 99-100% of the IT tests once we stablized some values, we started processing the system properties by deriving a reasonable default. This can be overriden but when not overriden it will work 99%-100% of the time as well.

private static final String reservationJNDI = System.getProperty("jndi.name.reservation",

    "ejb:basicejb-ear/basicejb-ejb/ReservationEJB!"+ReservationRemote.class.getName());

Let's show this in action by loading our application into the IDE, deploying the EAR and WAR, and executing the IT tests from within Eclipse.

Getting to the point where you can run and debug the IT test within the IDE is a significant amount of the work involved with being able to debug the code on the server-side. At this point you have that code surrounded and now all you have to do is peek inside. Lets look at how this is done with a remote server first.

In the previous section we showed how the stand-alone server required some setup but was very easy to establish a debugging session once much of the one-time setup was complete. In this method we are going to show how that setup can get even easier if you are willing and able to run the application server in the same JVM as the IDE.