Running the examples in Hudson would be ideal; however, the examples need to
be reorganized to trigger a Maven build failure when they fail and they need
to be executed during the build. Most of the examples are written as a
standalone Java class with a main method. The client and server profiles
are used to start the client and server applications. Running a Maven build
(clean install for example) will never trigger the actual execution of the
example code for most, if not all of the examples. Additionally, with the
way the samples are currently written, they do not report failure in a way
that integrates with the Maven build.
The following is a description of how I have provided examples that are also
executed as part of the build process to ensure that the examples are always
working.
I have released example code to a client before where we created the example
clients as JUnit tests and the example server as a standalone Java class
that can be launched with the JVM or programmatically. We then configured
the Maven build to run the JUnit test as part of the build. The JUnit test
uses a system property to determine if it should start its own server
programmatically or assume that the user launched one in a separate process.
This flag allows the same JUnit test to run during the build and to also be
run from the client profile after the user has run the server profile. So
what you get is the sample running as part of the build using JUnit to cause
a build failure if anything doesn't work right and the ability for the end
user to still launch the client and server separately. This approach
integrates well with Spring-test so pulling in Spring configuration is super
simple on the client side (if we want to add that layer of indirection into
the samples is another question entirely). Finally, this approach can also
work with the server running in a container by using Cargo or PAX
Exam/Runner.
The Maven POM profiles:
<profile>
<id>client</id>
<build>
<defaultGoal>test</defaultGoal>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<startServer>false</startServer>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>server</id>
<build>
<defaultGoal>process-test-classes</defaultGoal>
<plugins>
<!-- Note that this plug-in is used due to MEXEC-24 in the Maven 2
Exec Plug-in
and the need to start the server in an external JVM. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>process-test-classes</phase>
<configuration>
<tasks>
<java
classname="examples.common.impl.StandAloneRunner"
fork="true"
classpathref="maven.test.classpath">
<arg value="classpath:/server-context.xml"/>
</java>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
--------------------------------------------------------------------------
Standalone server runner:
package examples.common.impl;
import org.springframework.context.support.ClassPathXmlApplicationContext;
/**
* A utility class for running a server based on configuration in a Spring
* context file. This class is intended to serve as the bootstrap code in a
* separate JVM or as a utility for starting and stopping the server in the
same
* JVM.
*/
public class StandAloneRunner {
/**
* The Spring context.
*/
private ClassPathXmlApplicationContext ctx = null;
/**
* Starts a new instance and configures a shutdownhook to stop the
instance
* on JVM shutdown.
* <p/>
* Takes a single argument, the location of the Spring context file to
load
* in init-param style, i.e. with distinct locations separated by
commas,
* semicolons or whitespace.
*
* @param args
* the arguments
*/
public static void main(String[] args) {
System.out.println("Loading Service...");
if (args.length != 1) {
throw new IllegalArgumentException(
"The first argument must be the location of a Spring
context file.");
}
final StandAloneRunner runner = new StandAloneRunner(args[0]);
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
runner.stop();
}
});
runner.start();
System.out.println("Loaded Service.");
System.out.println("Press Ctrl-c to terminate the service.");
}
/**
* Creates a new instance.
*
* @param configLocation
* the config locations for the application context in
init-param
* style, i.e. with distinct locations separated by commas,
* semicolons or whitespace.
*/
public StandAloneRunner(String configLocation) {
this.ctx = new ClassPathXmlApplicationContext();
this.ctx.setConfigLocation(configLocation);
}
/**
* Starts/restarts the instance.
*/
public void start() {
this.ctx.refresh();
}
/**
* Stops the instance.
*/
public void stop() {
if (this.ctx != null) {
this.ctx.close();
}
}
}
--------------------------------------------------------------------------
JUnit test example:
public class MyTest {
...
/**
* The runner used to run the server for this test.
*/
private static StandAloneRunner runner = null;
/**
* Starts the server described by the /server-context.xml file located
on
* the classpath if and only if the system property {...@code startServer}
is
* not {...@code false}. This flag allows this test to be executed against
a
* server that it manages using {...@link #runner} or against an externally
* managed service.
*/
@BeforeClass
public static void startServer() {
if (Boolean.valueOf(System.getProperty("startServer", "true"))) {
MyTest.runner = new StandAloneRunner(
"classpath:server-context.xml");
MyTest.runner.start();
}
}
/**
* Stops the server optionally started by {...@link #startServer()}.
*/
@AfterClass
public static void stopServer() {
try {
if (MyTest.runner != null) {
MyTest.runner.stop();
}
}
finally {
MyTest.runner = null;
}
}
}
David Valeri
---------------------------
http://davidvaleri.wordpress.com/
http://twitter.com/DavidValeri
-----Original Message-----
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Monday, August 23, 2010 9:59 AM
To: dev@cxf.apache.org
Cc: Sergey Beryozkin
Subject: Re: How to run interopfest?
On Monday 23 August 2010 9:53:58 am Sergey Beryozkin wrote:
> Hi
>
> On Mon, Aug 23, 2010 at 12:51 PM, Glen Mazza <glen.ma...@gmail.com> wrote:
> > How does one run the interopfest tests? If I make a change to the
> > stsclient
> > I would want to make sure it doesn't break anything.
> >
> > I do 'mvn install -Pfastinstall' from the trunk, followed by 'mvn
> > install'
>
> in /api, and then doing 'install' in /distribution.
> Once the distribution is built, I go to target/..../samples/ and do the
> 'mvn install' in whatever demo project I need to run.
> Ex, I'd go ws_security/interopfest/wstrust10 and do 'mvn install'.
> Apparently in CXF 2.3, one needs to do 'mvn install' directly from
> 'samples' or alternatively you can modify the poms of individual demos by
> adding <relativePath> to the parent properties.
Ah.. The interopfest are down an extra directory. They would need the
relativePath added. Good catch. Most of the demos that are just in the
subdir directly under samples wouldn't as maven automatically looks in ".."
> Finally, I run the demo according to README or pom.xml,
>
> mvn -Pclient
>
> in the case of WS-Trust demos.
>
> I'm wondering, should we resume the discussion about running demos in
> Hudson ?
Well, they are already building as part of the deploy builds:
https://hudson.apache.org/hudson/view/CXF/job/CXF-trunk-deploy/378/
although the Interopfest ones are not as they require the MS servers to be
up
and running and such and I didn't want the builds failing due to that.
Dan
> cheers, Sergey
>
> > Glen
> > --
> > View this message in context:
> >
http://cxf.547215.n5.nabble.com/How-to-run-interopfest-tp2644543p2644543.
> > html Sent from the cxf-dev mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
