Saturday, October 3, 2015

Validating XML against an XSD with xmllint

Quick reference for how to validate an XML document against a schema using xmlint:
  $ xmllint --noout --schema stats.xsd example-stat.xml 
  example-stat.xml validates
Here is what you might see for an invalid document:
  $ xmllint --noout --schema stats.xsd junk.xml
  junk.xml:1: element event: Schemas validity error : Element 'event': No matching global declaration available for the validation root.
  junk.xml fails to validate

Thursday, October 1, 2015

Groovy: Closure Currying Example

Really simple example of closure currying so I do not forget it and hope that it helps someone else:
def addTo = { Map m, String k, Object v ->
    m[k] = v

Map elements = [:]

addTo elements, 'a', 1

def addTo2 = addTo.curry(elements)

addTo2 'c', 3

assert elements == ['a':1, 'c':3]

Sunday, March 8, 2015

Comparing JSON Strings with Jackson

Here's a quick way to compare two JSON String using Jackson. While we could always do a simple String compare, this method allows us to keep the expected JSON in a readable format, such as pretty-printed in a test resource:

import com.fasterxml.jackson.databind.ObjectMapper

class JsonAssert {

    static ObjectMapper mapper = new ObjectMapper()

    static void areEqual(String json1, String json2) {
        def tree1 = mapper.readTree json1
        def tree2 = mapper.readTree json2

        assert tree1.equals(tree2)


The above can be called from an expect: or then: block in a Spock specification.

Saturday, February 14, 2015

Simple Shell Script for Maven Integration Tests

Here's a simple shell script it took me forever to add to make it easier for me to run an integration test with Maven:

$ cat ~/bin/it
mvn clean verify -Dit -Dit.test=$1
I just have to remember the test name now instead of repeatedly typing the above:
$ it MyIntegrationSpec

Sunday, November 30, 2014

Subversion: Recovering Password from Local Cache

Subversion: Recovering Password from Local Cache

If you've forgotten your Subversion password, you should be able to retrieve it from another machine where you've succesfully made a commit before.

If you look in the local cache for your server's authentication type, you should see a series a files with hexadecimal names.

For example, for a server using simple or basic authentication:

  $ ls ~/.subversion/auth/svn.simple
  2af94d688c4073220b0a6af1b5884861  887652dff29c33e3f09394ea7379fac9

If you then look in one of the file, you should see your password:

  $ cat ~/.subversion/auth/svn.simple/2af94d688c4073220b0a6af1b5884861 | grep -A 2 password
    V 9

The above commands and locations are for a Linux box, but something similar should work on other OSes.

Wednesday, November 5, 2014

Spock and Objenesis: Resolving IllegalAccessError

Spock and Objenesis: Resolving IllegalAccessError

When mocking some classes with Spock in one of the usual ways, we often may need to include cglib. We also have to add objensis as well.

In one our modules, the latter was removed, leading to the below type of error that did not directly point out the cause:

java.lang.IllegalAccessError: tried to access method<init>(Lorg/company/service/export/ExportRequest$Builder;)V from class$$EnhancerByCGLIB$$1969beb7
 at org.spockframework.mock.runtime.MockInstantiator.instantiate(
 at org.spockframework.mock.runtime.ProxyBasedMockFactory$CglibMockFactory.createMock(
 at org.spockframework.mock.runtime.ProxyBasedMockFactory.create(
 at org.spockframework.mock.runtime.JavaMockFactory.create(
 at org.spockframework.mock.runtime.CompositeMockFactory.create(
 at org.spockframework.lang.SpecInternals.createMock(
 at org.spockframework.lang.SpecInternals.createMockImpl(
 at org.spockframework.lang.SpecInternals.MockImpl(

For our mocking, we would define the mock at the field level like:

    ExportRequest request = Mock()

After adding objenesis, the error was resolved:


Saturday, November 1, 2014

Sending Email with Spring

Sending Email with Spring

At work, we were using an in-house dependnecy to send text-based internal emails out the door of one our webapps for notifications. The solution worked will for us, but did more than just send emails. As a result, depending on it introduced a large dependency tree to our application.

Since the artifact simply appeared to be a wrapper around Spring, which we were using directly anyway, we thought it might be better to write our own little solution instead, and simplify our application's dependency graph.

Below I'll describe some "highlights". A full project example can be found here: spring-mail-example

In our business processes, we send notifications to same email address and from the same sender. The only thing that may change is the subject of the email (success vs. failure) and the contents of the email. So we wanted a simple interface that just took both these parameters:

interface Sender {
    void send(String subject, String text)

Below is an implementation of the interface that:

  • Sends a simple MimeMessage with type text/html.
  • Expects the sender and recipient email address to be injected.
  • Expects the name and port of the mail host to use to be injected.
  • Creates an instance of JavaMailSender to help simplify configuration for the user.

The code:

class EmailSender implements Sender, InitializingBean {

    String mailHost
    int mailPort
    String fromAddress
    String toAddress

    protected JavaMailSender mailSender

    void send(String subject, String text) {
        try {
            mailSender.send htmlMessageWith(subject, text)
        catch (e) {
            logFailure e
            throw new MessageException(e)

        logSent toAddress, subject, text

    private MimeMessage htmlMessageWith(subject, text) {
        def mimeMessage = new MimeMessage(null)
        def messageHelper = new MimeMessageHelper(mimeMessage)

        messageHelper.with {
            addTo toAddress
            setFrom fromAddress
            setSubject subject
            setText text, true


    void afterPropertiesSet() throws Exception {
        mailSender = new JavaMailSenderImpl()
        mailSender.setHost mailHost
        mailSender.setPort mailPort

An example of how to configure the implementation with Spring:

    <bean class="prystasj.spring.mail.EmailSender">
       <property name="fromAddress" value=""/>
       <property name="toAddress" value=""/>
       <property name="mailHost" value=""/>
       <property name="mailPort" value="25"/>

In the end, we decided to go with this solution for our emails. While we now have code of our own to maintain, the resulting dependency tree is smaller, and we have control over adding any features we want, so for now the trade-off is worth it.