This post focus on Arquillian and ShrinkWrap and why they are awesome tools for integration testing of enterprise Java applications.

The source code used for this post is available on GitHub under the folder arquillian-shrinkwrap.

The tools

Arquillian

Arquillian brings test execution to the target runtime, alleviating the burden on the developer of managing the runtime from within the test or project build. To invert this control, Arquillian wraps a lifecycle around test execution that does the following:

• Manages the lifecycle of one or more containers
• Bundles the test case, dependent classes and resources as ShrinkWrap archives
• Deploys the archives to the containers
• Enriches the test case with dependency injection and other declarative services
• Executes the tests inside (or against) the containers
• Returns the results to the test runner for reporting

ShrinkWrap

ShrinkWrap, a central component of Arquillian, provides a simple mechanism to assemble archives like JARs, WARs, and EARs with a friendly, fluent API.

One of the major benefits of using Arquillian is that you run the tests in a remote container (i.e. application server). That means you’ll be testing the real deal. No mocks. Not even embedded runtimes!

Agenda

The following topics will be covered on this post:

• Configure the Arquillian infrastructure in a Maven-based Java project
• Inject EJBs and Managed Beans (CDI) directly in test instances
• Test Java Persistence API (JPA) layer
• Run Arquillian in client mode
• Run and debug Arquillian tests inside your IDE

Configure Maven to run integration tests

To run integration tests with Maven we need a different approach. By different approach I mean a different plugin: the Maven Failsafe Plugin.

The Failsafe Plugin is a fork of the Maven Surefire Plugin designed to run integration tests.

The Failsafe plugin goals are designed to run after the package phase, on the integration-test phase.

The Maven lifecycle has four phases for running integration tests:

• pre-integration-test: on this phase we can start any required service or do any action, like starting a database, or starting a webserver, anything…
• integration-test: failsafe will run the test on this phase, so after all required services are started.
• post-integration-test: time to shutdown all services…
• verify: failsafe runs another goal that interprets the results of tests here, if any tests didn’t pass failsafe will display the results and exit the build.

Configuring Failsafe in the POM:

<!-- clip -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12</version>
    <configuration>
        <skipTests>true</skipTests>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.12</version>
    <configuration>
        <encoding>UTF-8</encoding>
    </configuration>
    <executions>
        <execution>
            <id>integration-test</id>
            <goals>
                <goal>integration-test</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>
<!-- clip -->

By default, the Surefire plugin executes **/Test*.java, **/*Test.java, and **/*TestCase.java test classes. The Failsafe plugin will look for **/IT*.java, **/*IT.java, and **/*ITCase.java. If you are using both the Surefire and Failsafe plugins, make sure that you use this naming convention to make it easier to identify which tests are being executed by which plugin.

Configure Arquillian infrastructure in Maven

Configure your Maven project descriptor to use Arquillian by appending the following XML fragment:

<!-- clip -->
<repositories>
    <repository>
        <id>jboss-public-repository-group</id>
        <name>JBoss Public Repository Group</name>
        <url>http://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>1.0.0.CR8</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.jboss.arquillian.testng</groupId>
        <artifactId>arquillian-testng-container</artifactId>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>6.4</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec</groupId>
        <artifactId>jboss-javaee-6.0</artifactId>
        <version>3.0.1.Final</version>
        <type>pom</type>
        <scope>provided</scope>
    </dependency>
</dependencies>

<profiles>
    <profile>
        <id>jbossas-remote-7</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <dependencies>
            <dependency>
                <groupId>org.jboss.as</groupId>
                <artifactId>jboss-as-arquillian-container-remote</artifactId>
                <version>7.1.1.Final</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </profile>
</profiles>
<!-- clip -->

Arquillian has a vast list of container adapters. An Arquillian test can be executed in any container that is compatible with the programming model used in the test. However, throughout this post, only JBoss AS 7 is used.
Similarly to Java EE 6 Testing Part I, I chose to use TestNG testing framework, but again, JUnit should work just as well.

Create testable components

Before looking at how to write integration tests with Arquillian we first need to have a component to test.
A Session Bean is a common component in Java EE stack and will serve as test subject. In this post, I’ll be creating a very basic backend for adding new users to a database.

@Stateless
public class UserServiceBean {

    @PersistenceContext
    private EntityManager em;

    public User addUser(User user) {
        em.persist(user);
        return user;
    }

    // Annotation says that we do not need to open a transaction
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public User findUserById(Long id) {
        return em.find(User.class, id);
    }
}

In the code above I use JPA and so we need a persistence unit.
A persistence unit defines a set of all entity classes that are managed by EntityManager instances in an application. This set of entity classes represents the data contained within a single data store.
Persistence units are defined by the persistence.xml configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

    version="2.0">
    <persistence-unit name="example">
        <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
        <properties>
            <property name="hibernate.hbm2ddl.auto" value="create-drop" />
            <property name="hibernate.show_sql" value="true" />
        </properties>
    </persistence-unit>
</persistence>

In this example I’m using an example data source that uses H2 database and comes already configured with JBoss AS 7.

Finally, we also need an entity that maps to a table in the database:

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    @NotNull
    private String name;

    // Removed constructors, getters and setters for brevity

    @Override
    public String toString() {
        return "User [id=" + id + ", name=" + name + "]";
    }
}

Test JPA with Arquillian

We are now all set to write our first Arquillian test.
An Arquillian test case looks just like a unit test with some extras. It must have three things:

• Extend Arquillian class (this is specific to TestNG, with JUnit you need a @RunWith(Arquillian.class) annotation on the class)
• A public static method annotated with @Deployment that returns a ShrinkWrap archive
• At least one method annotated with @Test

public class UserServiceBeanIT extends Arquillian {

    private static final Logger LOGGER = Logger.getLogger(UserServiceBeanIT.class.getName());

    @Inject
    private UserServiceBean service;

    @Deployment
    public static JavaArchive createTestableDeployment() {
        final JavaArchive jar = ShrinkWrap.create(JavaArchive.class, "example.jar")
                .addClasses(User.class, UserServiceBean.class)
                .addAsManifestResource("META-INF/persistence.xml", "persistence.xml")
                // Enable CDI
                .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));

        LOGGER.info(jar.toString(Formatters.VERBOSE));

        return jar;
    }

    @Test
    public void callServiceToAddNewUserToDB() {
        final User user = new User("Ike");
        service.addUser(user);
        assertNotNull(user.getId(), "User id should not be null!");
    }
}

This test is straightforward, it inserts a new user and checks that the id property has been filled with the generated value from the database.
Since the test is enriched by Arquillian, you can inject EJBs and managed beans normally using @EJB or @Inject annotations.
The method annotated with @Deployment uses ShrinkWrap to build a JAR archive which will be deployed to the container and to which your tests will be run against. ShrinkWrap isolates the classes and resources which are needed by the test from the remainder of the classpath, you should include every component needed for the test to run inside the deployment archive.

Client mode

Arquillian supports three test run modes:

• In-container mode is to test your application internals. This gives Arquillian the ability to communicate with the test, enrich the test and run the test remotely. In this mode, the test executes in the remote container; Arquillian uses this mode by default.
• Client mode is to test how your application is used by clients. As opposed to in-container mode which repackages and overrides the test execution, the client mode does as little as possible. It does not repackage your @Deployment nor does it forward the test execution to a remote server. Your test case is running in your JVM as expected and you’re free to test the container from the outside, as your clients see it. The only thing Arquillian does is to control the lifecycle of your @Deployment.
• Mixed mode allows to mix the two run modes within the same test class.

To run Arquillian in client mode lets first build a servlet to be tested:

@WebServlet("/User")
public class UserServlet extends HttpServlet {

    private static final long serialVersionUID = -7125652220750352874L;

    @Inject
    private UserServiceBean service;

    @Override
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/plain");

        PrintWriter out = response.getWriter();
        out.println(service.addUser(new User("Ike")).toString());
        out.close();
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException,
            IOException {
        doGet(request, response);
    }
}

And now lets test it:

public class UserServletIT extends Arquillian {

    private static final Logger LOGGER = Logger.getLogger(UserServletIT.class.getName());

    // Not managed, should be used for external calls (e.g. HTTP)
    @Deployment(testable = false)
    public static WebArchive createNotTestableDeployment() {
        final WebArchive war = ShrinkWrap.create(WebArchive.class, "example.war")
                .addClasses(User.class, UserServiceBean.class, UserServlet.class)
                .addAsResource("META-INF/persistence.xml")
                // Enable CDI
                .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));

        LOGGER.info(war.toString(Formatters.VERBOSE));

        return war;
    }

    @RunAsClient // Same as @Deployment(testable = false), should only be used in mixed mode
    @Test(dataProvider = Arquillian.ARQUILLIAN_DATA_PROVIDER)
    public void callServletToAddNewUserToDB(@ArquillianResource URL baseURL) throws IOException {
        // Servlet is listening at <context_path>/User
        final URL url = new URL(baseURL, "User");
        final User user = new User(1L, "Ike");

        StringBuilder builder = new StringBuilder();
        BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream()));
        String line;

        while ((line = reader.readLine()) != null) {
            builder.append(line);
        }
        reader.close();

        assertEquals(builder.toString(), user.toString());
    }
}

Although this test is very simple, it allows you to test multiple layers of you application with a single method call.

Run tests inside Eclipse

You can run an Arquillian test from inside your IDE just like a unit test.

Run an Arquillian test

(Click on the images to enlarge)

1. Install TestNG and JBoss Tools Eclipse plugins.
2. Add a new JBoss AS server to Eclipse:
   
3. Start JBoss AS server:
   
4. Run the test case from Eclipse, right click on the test file on the Project Explorer and select Run As > TestNG Test:
   

The result should look similar to this:

Debug an Arquillian test

(Click on the images to enlarge)

Since we are using a remote container Debug As > TestNG Test does not cause breakpoints to be activated.
Instead, we need to start the container in debug mode and attach the debugger. That’s because the test is run in a different JVM than the original test runner.
The only change you need to make to debug your test is to start JBoss AS server in debug mode:

1. Start JBoss AS server debug mode:
   
2. Add the breakpoints you need to your code.
3. And debug it by right clicking on the test file on the Project Explorer and selecting Run As > TestNG Test:
   

More resources

I hope to have been able to highlight some of the benefits of Arquillian.
For more Arquillian awesomeness take a look at the following resources:

• Arquillian Guides
• Arquillian Community
• Arquillian Git Repository

Related Posts

• Unit Testing JBoss 5 Services
• Java EE 6 Testing Part I – EJB 3.1 Embeddable API
• Maven 2 Cobertura Plugin – Updated
• JBoss PojoCache configuration
• JBoss AS 5.0 is out!

Unlike traditional Java EE server-based execution, embeddable usage allows client code and its corresponding enterprise beans to run within the same JVM and class loader. This provides better support for testing, offline processing (e.g. batch), and the use of the EJB programming model in desktop applications.
[...]
The embeddable EJB container provides a managed environment with support for the same basic services that exist within a Java EE runtime: injection, access to a component environment, container-managed transactions, etc. In general, enterprise bean components are unaware of the kind of managed environment in which they are running. This allows maximum reusability of enterprise components across a wide range of testing and deployment scenarios without significant rework.

Let’s look at an example.

Start by creating a Maven project and add the embeddable GlassFish dependency.
I chose to use TestNG testing framework, but JUnit should work just as well.

<dependencies>
    <dependency>
        <groupId>org.glassfish.extras</groupId>
        <artifactId>glassfish-embedded-all</artifactId>
        <version>3.1.2</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>6.4</version>
        <scope>test</scope>
    </dependency>
    <!--
        The javaee-api is stripped of any code and is just used to
        compile your application. The scope provided in Maven means
        that it is used for compiling, but is also available when
        testing. For this reason, the javaee-api needs to be below
        the embedded Glassfish dependency. The javaee-api can actually
        be omitted when the embedded Glassfish dependency is included,
        but to keep your project Java-EE 6 rather than GlassFish,
        specification is important.
    -->
    <dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-api</artifactId>
        <version>6.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

Here’s a simple Stateless session bean:

@Stateless
public class HelloWorld {
    public String hello(String message) {
        return "Hello " + message;
    }
}

It exposes business methods through a no-interface view.
There is no special API it must use to be capable of embeddable execution.

Here is some test code to execute the bean in an embeddable container:

public class HelloWorldTest {
    private static EJBContainer ejbContainer;

    private static Context ctx;

    @BeforeClass
    public static void setUpClass() throws Exception {
        // Instantiate an embeddable EJB container and search the
        // JVM class path for eligible EJB modules or directories
        ejbContainer = EJBContainer.createEJBContainer();

        // Get a naming context for session bean lookups
        ctx = ejbContainer.getContext();
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        // Shutdown the embeddable container
        ejbContainer.close();
    }

    @Test
    public void hello() throws NamingException {
        // Retrieve a reference to the session bean using a portable
        // global JNDI name
        HelloWorld helloWorld = (HelloWorld)
                ctx.lookup("java:global/classes/HelloWorld");

        // Do your tests
        assertNotNull(helloWorld);
        String expected = "World";
        String hello = helloWorld.hello(expected);
        assertNotNull(hello);
        assertTrue(hello.endsWith(expected));
    }
}

The source code is available on GitHub under the folder ejb31-embeddable.

For a step by step tutorial with a JPA example take a look at Using the Embedded EJB Container to Test Enterprise Applications from NetBeans docs.

While this new API is a step forward, I still have an issue with this approach: you are bringing the container to the test. This requires a specialized container which is different from your production environment.

In Java EE 6 Testing Part II, I will introduce Arquillian and ShrinkWrap.
Arquillian, a powerful container-oriented testing framework layered atop TestNG and JUnit, gives you the ability to create the production environment on the container of your choice and just execute tests in that environment (using the datasources, JMS destinations, and a whole lot of other configurations you expect to see in production environment). Instead of bringing your runtime to the test, Arquillian brings your test to the runtime.

Related Posts

• Java EE 6 Testing Part II – Introduction to Arquillian and ShrinkWrap
• Maven 2 Cobertura Plugin – Updated
• Unit Testing JBoss 5 Services
• Stripes framework and EJB3
• Maven 2 Cobertura Plugin

The code is pretty much self explanatory:

/*
 * queryParameters -> handles the query string parameters
 * queryString -> the query string without the fist '?' character
 * re -> the regular expression
 * m -> holds the string matching the regular expression
 */
var queryParameters = {}, queryString = location.search.substring(1),
    re = /([^&=]+)=([^&]*)/g, m;

// Creates a map with the query string parameters
while (m = re.exec(queryString)) {
    queryParameters[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}

// Add new parameters or update existing ones
queryParameters['newParameter'] = 'new parameter';
queryParameters['existingParameter'] = 'new value';

/*
 * Replace the query portion of the URL.
 * Query.param() -> create a serialized representation of an array or
 *     object, suitable for use in a URL query string or Ajax request.
 */
location.search = $.param(queryParameters);

You can clearly improve the regular expression, but the one above meet my needs.

Related Posts

• samaxesJS JavaScript library updates
• Stripes framework and jQuery Autocomplete
• Stripes framework and jQuery: AJAX forms and HTTP Session Validation
• samaxesJS JavaScript Controls
• IE7 JavaScript library

Fred Wilson considered it at 10 Golden Principles of Successful Web Apps as the #1 principle for successful web apps.

First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it.

Faster website means more revenue and traffic

• Amazon: 100 ms of extra load time caused a 1% drop in sales (source: Greg Linden, Amazon).
• Google: 500 ms of extra load time caused 20% fewer searches (source: Marrissa Mayer, Google).
• Yahoo!: 400 ms of extra load time caused a 5–9% increase in the number of people who clicked “back” before the page even loaded (source: Nicole Sullivan, Yahoo!).

Google experiments reached similar results:

Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment). That’s 0.2% to 0.6% fewer searches for changes under half a second!

And speed is now a factor contributing to Google Page Rank:

Google, in their ongoing effort to make the Web faster, blogged last month that “we’ve decided to take site speed into account in our search rankings.” This is yet another way in which improving web performance will have a positive impact on the bottom line.

The good news is that some of the most important speed optimizations can be easily done with simple .htaccess rules.
These rules can make any website faster by compressing content and enabling browser cache, and follow the Best Practices for Speeding Up Your Web Site from Yahoo!’s Exceptional Performance team.

Compress content

Compression reduces response times by reducing the size of the HTTP response.
It’s worthwhile to gzip your HTML documents, scripts and stylesheets. In fact, it’s worthwhile to compress any text response including XML and JSON.
Image and PDF files should not be gzipped because they are already compressed. Trying to gzip them not only wastes CPU but can potentially increase file sizes.

To compress your content, Apache 2 comes bundled with the mod_deflate module.

The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.

The following rule will gzip all your *.css, *.js, *.html, *.html, *.xhtml, and *.php files:

<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

In previous versions of Apache, you can use mod_gzip.

Enable browser cache

Web page designs are getting richer and richer over time, which means more scripts, stylesheets and images in the page. A first-time visitor to your page will make several HTTP requests to download all your sites files, but by using the Expires and Cache-Control headers you make those files cacheable. This avoids unnecessary HTTP requests on subsequent page views.

Apache enables those headers thanks to mod_expires and mod_headers modules.

The mod_expires module controls the setting of the Expires HTTP header and the max-age directive of the Cache-Control HTTP header in server responses.
To modify Cache-Control directives other than max-age, you can use the mod_headers module.

The mod_headers module provides directives to control and modify HTTP request and response headers. Headers can be merged, replaced or removed.

Rule for setting Expires headers:

# BEGIN Expire headers
<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 5 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
  ExpiresByType text/html "access plus 600 seconds"
  ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers

Rule for setting Cache-Control headers:

# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
  <filesMatch "\.(ico|jpe?g|png|gif|swf)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(css)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(js)$">
    Header set Cache-Control "private"
  </filesMatch>
  <filesMatch "\.(x?html?|php)$">
    Header set Cache-Control "private, must-revalidate"
  </filesMatch>
</ifModule>
# END Cache-Control Headers

Note 1: There is no need to set max-age directive with Cache-Control header since it is already set by mod_expires module.
Note 2: must-revalidate means that once a response becomes stale it has to be revalidated; it doesn’t mean that it has to be checked every time.

Disable HTTP ETag header

ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date.

The problem with ETags is that they typically are constructed using attributes that make them unique to a specific server hosting a site.
ETags won’t match when a browser gets the original component from one server and later tries to validate that component on a different server.

In Apache, this is done by simply adding the FileETag directive to your configuration file:

# BEGIN Turn ETags Off
FileETag None
# END Turn ETags Off

Last-Modified header

In my previous posts I stated that:

If you remove the Last-Modified and ETag header, you will totally eliminate If-Modified-Since and If-None-Match requests and their 304 Not Modified responses, so a file will stay cached without checking for updates until the Expires header indicates new content is available!

Well, I was wrong and this is why: we still want Last-Modified header for static files. If a user presses the refresh button, then browser will send a conditional request and server will respond a 304 Not Modified. If you disable both Last-Modified and ETag, the browser will have to download the whole content again whenever a user presses refresh.

Merge and minify your static files

Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.
Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times.

See Combine and minimize JavaScript and CSS files for faster loading for more information on this topic.

Web performance tools

Always check your changes. Use either YSlow or Page Speed browser plugins.
They are super easy to use and the best tools currently available for the job.

Final file

# BEGIN Compress text files
<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>
# END Compress text files

# BEGIN Expire headers
<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 5 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
  ExpiresByType text/html "access plus 600 seconds"
  ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers

# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
  <filesMatch "\.(ico|jpe?g|png|gif|swf)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(css)$">
    Header set Cache-Control "public"
  </filesMatch>
  <filesMatch "\.(js)$">
    Header set Cache-Control "private"
  </filesMatch>
  <filesMatch "\.(x?html?|php)$">
    Header set Cache-Control "private, must-revalidate"
  </filesMatch>
</ifModule>
# END Cache-Control Headers

# BEGIN Turn ETags Off
FileETag None
# END Turn ETags Off

Related Posts

• Speed up your site by compressing and caching your content with .htaccess
• .htaccess – gzip and cache your site for faster loading and bandwidth saving
• Combine and minimize JavaScript and CSS files for faster loading
• JBoss PojoCache configuration
• J2EE cache filter

This project escapes all the parameters that Stripes binds during its Validation & Binding phase using a wrapped request object (a convenient implementation of the HttpServletRequest interface).

The code follows the XSS (Cross Site Scripting) security guidance posted at OWASP (Open Web Application Security Project).

Please feel free to report any bug you find in the project Issue Tracking.

Related Posts

• Java Web Development with Stripes framework
• Stripes framework and jQuery Autocomplete
• Stripes framework and jQuery: AJAX forms and HTTP Session Validation
• BIRT/Stripes framework example
• Stripes framework and EJB3

This bug is fixed on versions 2.2 or higher, and consequently, that workaround does not work anymore.
For those reading my previous article and having difficulties configuring the plugin, this is my actual configuration.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.5</version>
            <configuration>
                <systemPropertyVariables>
                    <net.sourceforge.cobertura.datafile>target/cobertura/cobertura.ser</net.sourceforge.cobertura.datafile>
                </systemPropertyVariables>
                <!-- for JDK6 Support -->
                <argLine>-Dsun.lang.ClassLoader.allowArraySyntax=true</argLine>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <check>
                    <haltOnFailure>false</haltOnFailure>
                    <regexes>
                        <regex>
                            <pattern>com.samaxes.business.*</pattern>
                            <branchRate>80</branchRate>
                            <lineRate>80</lineRate>
                        </regex>
                        <regex>
                            <pattern>com.samaxes.persistence.*</pattern>
                            <branchRate>80</branchRate>
                            <lineRate>80</lineRate>
                        </regex>
                    </regexes>
                </check>
                <instrumentation>
                    <includes>
                        <include>com/samaxes/business/**/*.class</include>
                        <include>com/samaxes/persistence/**/*.class</include>
                    </includes>
                </instrumentation>
            </configuration>
        </plugin>
    </plugins>
</build>
<reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-report-plugin</artifactId>
            <version>2.5</version>
            <reportSets>
                <reportSet>
                    <reports>
                        <report>report-only</report>
                    </reports>
                </reportSet>
            </reportSets>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.3</version>
        </plugin>
    </plugins>
</reporting>

Related Posts

• Maven 2 Cobertura Plugin
• Maven Minify Plugin using YUI Compressor
• Using Maven 2, XDoclet 2, and Hibernate 3
• Java EE 6 Testing Part II – Introduction to Arquillian and ShrinkWrap
• Java EE 6 Testing Part I – EJB 3.1 Embeddable API

Changes include:

• Reduced file size by removing duplicated code using a for loop when defining and processing indexes (1.8KB for the minified jQuery TOC plugin).
• Added a new option: context, allowing the TOC to list headings from only a portion of the page.

Please report any bug you may find in the project Issue Tracking.

Related Posts

• Changing URL parameters with jQuery
• Stripes framework and jQuery Autocomplete
• Stripes framework and jQuery: AJAX forms and HTTP Session Validation
• samaxesJS JavaScript Controls
• IE7 JavaScript library

By adding Java to their App Engine, Google has opened the door for a whole slew of languages that have been implemented on the JVM, now including PHP via Quercus.

This weekend I decided to give it a try and deploy an old tutorial of mine – PHP Tutorials – on GAE.

I must admit that I was pleasantly surprised by how effortless it was. OK, it’s a very rudimentary PHP application, the only PHP code used was to run the examples described on the code blocks and do some includes; nevertheless I didn’t feel the need to change a single line of code.

Also, deploying a Java application to GAE is simpler than a Python one. Not only because you have a very handy Eclipse plugin, but you will also find configuring the file appengine-web.xml a lot easier when compared to app.yaml.

All you need to do in order to deploy a PHP application, at least as simple as the one I’ve tried, is to follow these steps:

1. Install Google Plugin for Eclipse.
2. Create a Web Application Project in eclipse. The complete project directory looks like this:

   Guestbook/
     src/
       ...Java source code...
       META-INF/
         ...other configuration...
     war/
       ...JSPs, images, data files...
       WEB-INF/
         ...app configuration...
         lib/
           ...JARs for libraries...
         classes/
           ...compiled classes...
   

3. Copy all your PHP and static files to your-project/war.
4. Download Quercus binary (WAR file).
5. Unzip it and copy all files inside quercus.war/WEB-INF/lib to your-project/war/WEB-INF/lib.
6. Edit your deployment descriptor file web.xml. Mine looks like this:

   <?xml version="1.0" encoding="utf-8"?>
   <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
       version="2.5">
       <description>PHP Tutorial</description>
   
       <servlet>
           <servlet-name>Quercus Servlet</servlet-name>
           <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
       </servlet>
   
       <servlet-mapping>
           <servlet-name>Quercus Servlet</servlet-name>
           <url-pattern>*.php</url-pattern>
       </servlet-mapping>
   
       <welcome-file-list>
           <welcome-file>index.php</welcome-file>
       </welcome-file-list>
   </web-app>
   

7. Edit your configuration file appengine-web.xml. Mine looks like this:

   <?xml version="1.0" encoding="utf-8"?>
   <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   	<application>php-tutorials</application>
   	<version>1</version>
   
       <!-- Configure java.util.logging -->
       <system-properties>
           <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
       </system-properties>
   
       <static-files>
           <include path="/**" expiration="600s" />
           <include path="/**.png" expiration="30d" />
           <include path="/**.jpg" expiration="30d" />
           <include path="/**.gif" expiration="30d" />
           <include path="/**.ico" expiration="30d" />
           <include path="/**.swf" expiration="30d" />
           <include path="/**.css" expiration="7d" />
           <include path="/**.js" expiration="2d 12h" />
           <exclude path="/**.php" />
           <exclude path="/**.inc" />
       </static-files>
       <resource-files>
           <include path="/**.php" />
           <include path="/**.inc" />
       </resource-files>
   </appengine-web-app>
   

   The application element must match the application identifier of your application on Google App Engine.

Et voilà, you are done!

Now, run your application using the Run As >> Web Application command.
And finally, press the “Deploy App Engine Project” button to deploy to GAE.

Update: This article has been ported to the Miscellaneous section of my PHP Tutorial. Check Run PHP on Google App Engine page for updates.

Related Posts

• JBoss Web and PHP Install Tutorial
• Creating Offline Web Applications with Dojo Offline Tutorial
• More on offline web applications – Google Gears
• Web PHP framework – symfony
• BIRT and PHP Reporting

We need help with Phase 2: if you know a team contact for any of the targeted products that are claiming conformance to W3C Widgets, then would appreciate your help in making them aware of the results of the testing – Implementation Report: Widgets Packaging and Configuration.

Related Posts

• No Related Posts

The used source code is also available.

Related Posts

• Stripes framework XSS Interceptor
• Stripes framework and jQuery Autocomplete
• Stripes framework and jQuery: AJAX forms and HTTP Session Validation
• BIRT/Stripes framework example
• Stripes framework and EJB3