This the command that I use when I want to see what dependencies got bundled into my Spring Boot distribution JAR files:
jar -tvf filename.jar | grep jar$ | awk '{print $8}' | sed 's/BOOT-INF\/lib\///' | sort
I wanted to use a profile specific application.properties file for my Spring Boot application. But Gradle was not picking it up when I ran my launched with the following command:
gradle bootRun -Dspring.profiles.active=dev
The solution turned out be be simply adding the snippet below to my build.gradle file. This snippet is telling Gradle to pull in the system properties.
bootRun {
systemProperties = System.properties
}
The LDAP Maven Plugin was relying on the jcabi-aether library to resolve dependencies. When I first wrote the LDAP Maven Plugin I couldn’t find much information on how to resolve dependencies and jcabi-aether proved to be invaluable. Aether is dependency resolution framework used under the hood by Maven 3 and higher.
Aether was originally managed by Sonatype but it was moved to stewardship of the Eclipse foundation. Since Maven 3.1 the Eclipse version has been used.
Since I wanted to the maintain support for Maven 3.0.5 I decided to revert to the Maven 2 dependency resolution API.
In addition, I downgraded the version of ApacheDS used by the plugin to 1.5.5. I was having trouble resolving one of the transitive dependencies for 2.0.0-M15 during integration testing and I didn’t have any luck using the latest version (2.0.0-M17) or later. So I decided to downgrade for now and revisit the issue when ApacheDS 2.0.0 is released and documentation on embedding it becomes available.
The LDAP Maven Plugin is a Maven plugin that can:
The plugin provides the following goals to import or export content from a LDAP directory server:
The following file formats are supported:
The following POM fragment demonstrates how to load content into a LDAP directory server from a LDIF formatted file using the load goal of the LDAP Maven Plugin.
The following POM fragment demonstrates how to export content from a LDAP directory server to a LDIF formatted file using the dump goal of the LDAP Maven Plugin.
The following POM fragment demonstrates how to load content into a LDAP directory server from a DSML formatted file using the load goal of the LDAP Maven Plugin.
The following POM fragment demonstrates how to export content from a LDAP directory server to a DSML formatted file using the dump goal of the LDAP Maven Plugin.
The following POM fragment uses the run goal to launch an embedded LDAP directory server prior to the execution of the integration tests and then uses the stop goal to shutdown the embedded LDAP directory server upon completion of the integration tests.
The following LDAP client libraries can be used to connect to the embedded LDAP server:
The LDAPUnit library provides an assortment of assertion and verification methods for use in unit and integration test cases.
The LDAP Maven Plugin has been published in Maven Central at the following coordinates:
The LDAP Maven Plugin is made available under the Apache License and the source code is hosted on GitHub at https://github.com/bmatthews68/ldap-maven-plugin.
I am pleased to announce the availability of the In-Memory Database Maven Plugin version 1.3.0. This Maven plugin can be used to launch and shutdown an embedded in-memory SQL database within the Maven build life-cycle. During the launch the database can be seeded using DDL/DML scripts and/or DBUnit data sets.
The following database implementations are supported:
The following source file formats are supported:
The In-Memory Database Maven Plugin can be used to automate integration tests having a dependency on an external database server.
The POM here is from taken from the webpp integration test for the In-Memory Database Maven Plugin.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>webapp</groupId>
<artifactId>webapp</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>war</packaging>
<build>
<plugins>
<plugin>
<groupId>com.btmatthews.maven.plugins.inmemdb</groupId>
<artifactId>inmemdb-maven-plugin</artifactId>
<version>1.3.0</version>
<configuration>
<monitorKey>inmemdb</monitorKey>
<monitorPort>11527</monitorPort>
</configuration>
<executions>
<execution>
<id>run</id>
<goals>
<goal>run</goal>
</goals>
<phase>pre-integration-test</phase>
<configuration>
<daemon>true</daemon>
<type>derby</type>
<database>test</database>
<username>sa</username>
<password></password>
<sources>
<script>
<sourceFile>src/test/resources/create_database.sql</sourceFile>
</script>
<dataSet>
<sourceFile>src/test/resources/users.dbunit.xml</sourceFile>
</dataSet>
</sources>
</configuration>
</execution>
The In-Memory Database Maven Plugin is configured here to launch an in-memory Apache Derby database server as a daemon process during the pre-integration-test phase of the build life cycle. The database is initialised with a database schema and some seed data.
<execution>
<id>stop</id>
<goals>
<goal>stop</goal>
</goals>
<phase>post-integration-test</phase>
</execution>
The In-Memory Database Maven Plugin is configured here to shutdown the in-memory Apache Derby database server during the post-integration-test phase of the build life cycle.
</executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.8.v20121106</version>
<configuration>
<stopKey>jetty</stopKey>
<stopPort>19080</stopPort>
<daemon>true</daemon>
<webApp>
<contextPath>/</contextPath>
</webApp>
<jettyXml>src/test/jetty/jetty.xml</jettyXml>
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>9080</port>
<maxIdleTime>60000</maxIdleTime>
</connector>
</connectors>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
The Jetty Maven Plugin is configured here to launch the Jetty servlet container as a daemon process during the pre-integration-test phase of the build life cycle.
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
The Jetty Maven Plugin is configured here to shutdown the Jetty servlet container during the post-integration-test phase of the build life
cycle.
</executions>
<dependencies>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derbyclient</artifactId>
<version>10.9.1.0</version>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.3</version>
</dependency>
</dependencies>
</plugin>
The org.apache.derby:derbyclient and commons-dbcp:commons-dbcp dependencies are required in order to define the data source that connects to the in-memory Apache Derby database.
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.12.4</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
The Maven Failsafe Plugin is used to execute the integration tests during the integration-test phase of the build life cycle.
</plugins>
</build>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.btmatthews.selenium.junit4</groupId>
<artifactId>selenium-junit4-runner</artifactId>
<version>1.0.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
The com.btmatthews.selenium.junit4:selenium-junit-runner and junit:junit dependencies are required by the integration tests.
Add the following fragment of XML to the jetty.xml to define a data source for the test database.
<New class="org.eclipse.jetty.plus.jndi.Resource">
<Arg>
<Ref id="Server" />
</Arg>
<Arg>jdbc/test</Arg>
<Arg>
<New class="org.apache.commons.dbcp.BasicDataSource">
<Set name="username">sa</Set>
<Set name="password"></Set>
<Set name="url">jdbc:derby://localhost/memory:test</Set>
<Set name="driverClassName">org.apache.derby.jdbc.ClientDriver</Set>
</New>
</Arg>
</New>
Add the following <resource-ref> to the
jetty.xml available inside the web application:
<resource-ref>
<res-ref-name>jdbc/test</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
The In-Memory Database Maven Plugin has been published in Maven Central at the following coordinates:
<plugin>
<groupId>com.btmatthews.maven.plugins.inmemdb</groupId>
<artifactId>inmemdb-maven-plugin</artifactId>
<version>1.3.0</version>
</plugin>
This project contains contributions from:
The In-Memory Database Maven Plugin is made available under the Apache License and the source code is hosted on GitHub at https://github.com/bmatthews68/inmemdb-maven-plugin.
On a recent project I had problems deploying a web application built on the Struts 2 MVCframework to a fresh WebSphere installation. I wasted a lot of time labouring under the incorrect assumption (for once) that the architectural changes I had introduced in the latest sprint were the cause of my troubles.
But it turned out to be an environmental issue. We were deploying Struts 2 as a servlet filter and out of the box WebSphere does not support HTTP requests that are served by a servlet filter. A custom property called com.ibm.ws.webcontainer.invokefilterscompatibilty must be set for the web container. I guess I should have just deployed straight to the UAT environment!
Here is the procedure for setting the com.ibm.ws.webcontainer.invokefilterscompatibility custom property:
On my current assignment we are developing a multi-tennant web application and are giving the individual tennants the ability to customize the look and feel of the application. We are using Jackrabbit to host the style sheets, images and scripts that for each of the look and feels.
Initially I tried to deploy Jackrabbit as using the Shared J2EE Resource deployment model on WebSphere 6.1. Due to a leathal cocktail of stupidity and environmental constraints I couldn’t get it working earlier in the project and decided to settle for the Application Bundle deployment model.
Now we need to have more that one instance of the application running in the test environment and we’ve had to finally figure out how to get the Shared J2EE Resource deployment model up and running.
It turned out to be a lot easier than I exepcted. In order to get Jackrabbit working I just needed to customize the ra.xml deployment descriptor from jackrabbit-jca-2.2.x.rar by changing the <transaction-support/> element to from XATransaction to NoTransaction.
This change is necessary because Jackrabbit does not support local transactions and actually raises an exception when called by WebSphere.
Rather than have to customise this by hand I a put together the Maven POM below to build custom RAR for me. You must place the ra.xml deployment descriptor in src/main/rar/META-INF.
The SpringBeanJobFactory allows you to inject properties from the scheduler context, job data map and trigger data entries into the job bean. But there is no way out of the box to inject beans from the application context.
So I came up with the factory bean below that extends the SpringBeanJobFactory to add auto-wiring support:
I recently released Selenium JUnit 4 Runner. It is an extension for JUnit 4 providing a test runner to execute Selenium test cases. Both the Selenium 1.0 (Server) and 2.0 (Web Driver) APIs are supported.
Here is a very simple example:
@RunWith(SeleniumJUnit4ClassRunner.class)
@WebDriverConfiguration
public GoogleHomePageTest {
@SeleniumWebDriver
private WebDriver webDriver;
@Test
public void testGoogleSearch() {
webDriver.navigate().to("http://www.google.com");
assertEquals("Google", webDriver.getTitle());
}
}
The Selenium JUnit 4 Class Runner launches the Selenium web driver or connects to the Selenium server before executing any methods annotated with @BeforeClass. It then autowires any members of the test class or method rules that have been annotated with @SeleniumBrowser or @SeleniumWebDriver.
Selenium JUnit 4 Runner is available from Maven Central at the following coordinates:
<dependency>
<groupId>com.btmatthews.selenium.junit</groupId>
<artifactId>selenium-junit4-runner</artifactId>
<version>1.0.0</version>
<type>test</type>
</dependency>
The instructions below are based on Installing Maven 3 on Ubuntu 10.04 LTS Server from Luke Bourke. I am installing Maven 3.0.3 on Ubuntu 11.04 LTS Server with Oracle Java 6.
Download the Maven 3.0.3 binary distribution from your local mirror:
$ wget http://ftp.heanet.ie/mirrors/www.apache.org/dist/maven/binaries/apache-maven-3.0.3-bin.tar.gz
Uncompress the binary distribution and copy it to the /usr/local directory:
$ tar -zxf apache-maven-3.0.3-bin.tar.gz $ sudo cp -R apache-maven-3.0.3 /usr/local
Create symbolic link in /usr/bin:
$ sudo ln -s /usr/local/apache-maven-3.0.3/bin/mvn /usr/bin/mvn