You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/08/23 13:51:18 UTC
How to run interopfest?
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.
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.
Re: How to run interopfest?
Posted by Daniel Kulp <dk...@apache.org>.
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 <gl...@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
RE: How to run interopfest?
Posted by David Valeri <dv...@apache.org>.
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 <gl...@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
Re: How to run interopfest?
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 23 August 2010 9:53:58 am Sergey Beryozkin wrote:
> Hi
>
> On Mon, Aug 23, 2010 at 12:51 PM, Glen Mazza <gl...@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
Re: How to run interopfest?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Mon, Aug 23, 2010 at 12:51 PM, Glen Mazza <gl...@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.
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
?
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.
>
Re: How to run interopfest?
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 23 August 2010 7:51:18 am Glen Mazza 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.
There is a readme in each of the interopfest sample dirs that describe it in
more detail, but for the most part, just run "mvn -Pclient". There are extra
flags and profiles and such if you want to startup a CXF server and have the
client hit that server instead of the MS one and such, but if you just want to
have a CXF client hit the MS server, the above should work. (providing the MS
server is properly running and they didn't move things around again)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog