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
    password
    V 9
    mypassword

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 org.company.service.export.ExportRequest.<init>(Lorg/company/service/export/ExportRequest$Builder;)V from class org.company.service.export.ExportRequest$$EnhancerByCGLIB$$1969beb7
 at org.spockframework.mock.runtime.MockInstantiator.instantiate(MockInstantiator.java:33)
 at org.spockframework.mock.runtime.ProxyBasedMockFactory$CglibMockFactory.createMock(ProxyBasedMockFactory.java:92)
 at org.spockframework.mock.runtime.ProxyBasedMockFactory.create(ProxyBasedMockFactory.java:49)
 at org.spockframework.mock.runtime.JavaMockFactory.create(JavaMockFactory.java:51)
 at org.spockframework.mock.runtime.CompositeMockFactory.create(CompositeMockFactory.java:44)
 at org.spockframework.lang.SpecInternals.createMock(SpecInternals.java:47)
 at org.spockframework.lang.SpecInternals.createMockImpl(SpecInternals.java:282)
 at org.spockframework.lang.SpecInternals.MockImpl(SpecInternals.java:83)
 at org.company.service.export.RecordExporterSpec.$spock_initializeFields(RecordExporterSpec.groovy:141)

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

    ExportRequest request = Mock()

After adding objenesis, the error was resolved:

    <dependency>
        <groupId>cglib</groupId>
        <artifactId>cglib-nodep</artifactId>
        <version>2.2</version>
    </dependency>
    <dependency>
        <groupId>org.objenesis</groupId>
        <artifactId>objenesis</artifactId>
        <version>1.2</version>
    </dependency>

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

    @Override
    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
        }

        messageHelper.mimeMessage
    }

    @Override
    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="prystasj@company.org"/>
       <property name="toAddress" value="friend@company.org"/>
       <property name="mailHost" value="mailhost.company.org"/>
       <property name="mailPort" value="25"/>
   </bean>

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.