Well, the only addition to this would be that for it to be part of the hudson
builds, it would need to use dynamic ports for the client/server tests. With
hudson setup to run multiple builds on the machines and such, it really needs
to use dynamic ports.
We could just use the client/server stuff we have in cxf-testutils to write
"unit tests" that wrapper the current client and servers. That really
wouldn't be too involved. Someone just needs to tackle it. :-)
Dan
On Monday 23 August 2010 11:40:24 am David Valeri wrote:
> 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:[email protected]]
> Sent: Monday, August 23, 2010 9:59 AM
> To: [email protected]
> 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 <[email protected]> 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
[email protected]
http://dankulp.com/blog
