Aktualisierungen Juni, 2010 Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • Andreas Höhmann 12:05 am Tuesday, 1. June 2010 Permalink |
    Tags: integration-test, , maven2, port already bind, ,   

    Howto define jetty port for integration tests 

    Today I found a simple hack to define the jetty-port for a web-application integration test via command line.

    The problem was the defined „default“ jetty port (here 8080) … on the build system this port was already bind … so the integration test always failed :-(.

    My first idea was to call maven with external system property „jetty.port“ … (this worked already to start the web application on different ports):

    mvn clean integration-test -Pintegration-test -Djetty.port=1234

    The maven profile is here:

    ...
      <profile>
          <id>integration-test</id>
          <build>
            <defaultGoal>integration-test</defaultGoal>
            <plugins>
              <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <executions>
                  <execution>
                    <id>integration-tests</id>
                    <phase>integration-test</phase>
                    <goals>
                      <goal>test</goal>
                    </goals>
                    <configuration>
                      <forkMode>once</forkMode>
                      <suiteXmlFiles>
                        <suiteXmlFile>src/test/resources/Integration-Suite.xml</suiteXmlFile>
                      </suiteXmlFiles>
                    </configuration>
                  </execution>
                </executions>
              </plugin>
              <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>maven-jetty-plugin</artifactId>
                <version>${jetty.version}</version>
                <executions>
                  <execution>
                    <id>start-jetty</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                      <goal>run</goal>
                    </goals>
                    <configuration>
                      <daemon>true</daemon>
                      <connectors>
                        <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                          <port>${jetty.port}</port>
                        </connector>
                      </connectors>
                    </configuration>
                  </execution>
                  <execution>
                    <id>stop-jetty</id>
                    <phase>post-integration-test</phase>
                    <goals>
                      <goal>stop</goal>
                    </goals>
                  </execution>
                </executions>
              </plugin>
            </plugins>
          </build>
        </profile>
    

    I think with this TestNG test this should work … (the base class ImportantUseCaseTest contains some @Test annotated test methods):

    public class IntegrationTest extends ImportantUseCaseTest {
      @Override
      protected String getServerURL() {
        final String jettyPort = System.getProperty("jetty.port", "8080);
        return String.format("http://localhost:%s/webapp", jettyPort);
      }
    }
    

    But it doesn’t work 🙂

    If I call maven with „-Djetty.port=1234“ the jetty starts on 1234 but the integration test runs on 8080.  Hmmm …

    The solution was to change the surefire plugin configuration a little bit:

    ...
      <plugin>
         <artifactId>maven-surefire-plugin</artifactId>
         ...
         <configuration>
             ...
             <argLine>-Xmx512m -Djetty.port.integration=${jetty.port}</argLine>
         </configuration>
    

    and the test class:

    public class IntegrationTest extends ImportantUseCaseTest {
      @Override
      protected String getServerURL() {
        final String jettyPort = System.getProperty("jetty.port.integration", "8080);
        return String.format("http://localhost:%s/webapp", jettyPort);
      }
    }
    

    I guess that surefire with forkMode=once doesn’t pass the given system properties to the test jvm. Maybe with forkMode=never this problem not exists … but you can try this by yourself 😉

    Advertisements
     
  • Andreas Höhmann 12:30 am Monday, 27. April 2009 Permalink |
    Tags: , Example, , , Realworld,   

    Realworld JSF Application Story 

    Vielleicht hatte ich es in einem früheren Posting schonmal erwähnt, ich arbeite momentan für einen großen dt. Firma an einem Web 2.0 Projekt und das ist jetzt fertig 😀

    Ich konnte dabei all die wunderbaren „neuen“ Technologien einsetzen, u.a. JSF und damit eine funktionsfähige (also den Anforderungen des Kunden voll entsprechende) und zugleich performante „Web 2.0“ Applikation bauen.

    Die Applikation nimmt sich dem Thema „Sicherheitstechnik“ (für die Auskenner: ISO 13849-1 und IEC 62061) an.

    Mal kurz zu den verwendeten „Technologien/Frameworks/Tools/Ideen“:

    • Daten ziehen wir aus einer SAP Knowledgebase und aus einer Datenbank via OpenJPA
    • Services/Manager sind „normale“ Javaklassen (Stichwort Design-Pattern),
      als Kleber verwenden wir Spring (Stichwort Dependency Injection)
    • UI mit JBoss Richfaces (Stichwort Ajax), JSF + Facelets (Stichwort Xhtml-Template), jQuery, CSS, etc.
    • Buildsystem, Projektseiten mit Maven2
    • Continues Integration via TeamCity und Maven2
    • Tests hauptsächlich mit TestNG aber teilweise auch mit JUnit
    • Laden/Speichern von Benutzerdaten via XStream (FileupLoad via Tomahawk), das alles noch Versionskompatibel, d.h. selbsgestrickte XML-Transformationskette für DomainModell-Updates
    • PDF Reportgenerierung mit iText
    • Anbindung an ein „Single Sign On“ System via Spring Security, Webservices

    Im Rückblick kann ich sagen, dass eigentlich alles ohne größere Probleme miteinander funktioniert hat
    … so soll es sein 😀

     
  • Andreas Höhmann 17:18 am Wednesday, 15. October 2008 Permalink |
    Tags: request, scope, session, singleton, , test, , unit   

    Using Session/Request-Scoped SpringBeans in TestNG 

    Today i will show you how to use spring-beans (especially session-scoped respectively request-scoped) in Unittests.

    First of all … its easy to use a singleton bean (no scope) in a unit-test, load the ClassPathXmlApplicationContext with configLocations, use getBean(„name“) and then use the returned objects.

    But if you want use a enhanced (J2EE) spring-configuration in your unit-test you have to use the XmlWebApplicationContext.

    Lets use a simple example! Imagine you have different context-files, e.g. spring-beans-application.xml:

      <bean id="Foobar1" class="de.ahoehma.test.Foobar" scope="request"/>
      <bean id="Foobar2" class="de.ahoehma.test.Foobar" scope="session"/>
      <bean id="Foobar3" class="de.ahoehma.test.Foobar" />
    

    Then you have your unit-test:

    public class SpringBeansTestNg {
    
      //
      // XXX we have to define all spring-context-files - later this could be done via test-ng-provider or
      //     via spring with "spring-beans-*.xml" (i try it but it doesnt work)
      //
      private final String[] contextLocations = new String[]{
          "spring-beans-application.xml",
          "spring-beans-services.xml",
          "spring-beans-persistence.xml",
          "spring-beans-security.xml",};
    
      private ApplicationContext applicationContext;
    
      @BeforeTest
      private void loadApplicationContext() {
        final XmlWebApplicationContext xmlApplicationContext = new XmlWebApplicationContext();
        xmlApplicationContext.setConfigLocations(contextLocations);
        final MockServletContext servletContext = new MockServletContext("");
        xmlApplicationContext.setServletContext(servletContext);
        final RequestContextListener requestContextListener = new RequestContextListener();
        final MockHttpServletRequest request = new MockHttpServletRequest(servletContext);
        final ServletRequestEvent requestEvent = new ServletRequestEvent(servletContext, request);
        requestContextListener.requestInitialized(requestEvent);
        xmlApplicationContext.refresh();
        applicationContext = xmlApplicationContext;
      }
    
      /**
       * @return request scoped bean
       */
      private Foobar getFoobar1() {
        return (Foobar) applicationContext.getBean("Foobar1"); //$NON-NLS-1$
      }
    
     /**
       * @return session scoped bean
       */
      private Foobar getFoobar2() {
        return (Foobar) applicationContext.getBean("Foobar2"); //$NON-NLS-1$
      }
    
     /**
       * @return singleton bean
       */
      private Foobar getFoobar3() {
        return (Foobar) applicationContext.getBean("Foobar3"); //$NON-NLS-1$
      }
    }
    

    The magic happend in the loadApplicationContext.

    Try it 🙂

     
c
Neuen Beitrag erstellen
j
nächster Beitrag/nächster Kommentar
k
vorheriger Beitrag/vorheriger Kommentar
r
Antworten
e
Bearbeiten
o
zeige/verstecke Kommentare
t
Zum Anfang gehen
l
zum Login
h
Zeige/Verberge Hilfe
Shift + ESC
Abbrechen