A question on the Move applications to Liberty using the Migration Toolkit article just reminded me that the binary scanner isn’t just for migration. Use the binary scanner to take a deeper look at your simple and complex applications to gain a better understanding of how your application is put together. You might be surprised what you find.
When a question came in about an error on the binary scanner command line, I decided to scan the WAR file from WASdev/sample.jpa because I had just fixed a couple items in that code, and the WAR file was handy. The sample creates a simple Servlet and JPA entity and runs an integration test on the code. The sample also demonstrates how to use the Liberty Maven or Gradle plugins to download Liberty, install features, install the application, and run integration test. When working with the samples, choose the build tool you prefer.
Scan the application
To reproduce the problem, I ran the binary scanner against the project:
java -jar binaryAppScanner.jar ./jpaApp.war --all
With two Java classes that create a Servlet and JPA entity, I wasn’t expecting to get a bunch of feedback, but what I found was a bug in the sample. Furthermore, it is a bug we see often in applications.
The problem is that we tend to package JAR files in applications that are simply not needed because they are provided by the application server or by the Java runtime.
The first clue came from the inventory report diagram that shows two JAR files being included in this simple WAR file:
And the second clue was the correct guidance to not package Java EE implementation classes with the application:
And of course the fix is easy in the pom.xml. The
scope attribute was missing from these two dependencies and the default is
compile. By specifying the
provided, the JAR file is only used for compilation and is not packaged with the application.
<dependency> <groupId>javax.persistence</groupId> <artifactId>persistence-api</artifactId> <version>1.0.2</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.transaction</groupId> <artifactId>javax.transaction-api</artifactId> <version>1.2</version> <scope>provided</scope> </dependency>
For Gradle, these dependencies should be
providedCompile instead of
compile in the build.gradle file.
All the changes needed are shown in this pull request.
So my lesson for the day is that the binary scanner is not just for migration. It can give you a new perspective on your application. Check out the inventory and other reports, and pay attention to the problem areas it points out. It might be telling you something worth fixing.
Oh, and the original problem
Hyphens don’t always copy/paste well. The binary scanner does not interpret a UNICODE non-breaking hyphen (U+2011) the same as a regular hyphen (or minus), so when you enter your parameters like −−all, make sure the hyphen is really a hyphen (right there between the zero and the equal on my keyboard anyway).