cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: How to run interopfest?
Date Mon, 23 Aug 2010 19:13:23 GMT

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:dkulp@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.mazza@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
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message