Monday, February 8, 2021

SLF4j Logging performance: lazy argument evaluation

Sometimes we need to log a dynamically generated expressions that are very expensive to compute. For instance I had to log an object to yaml format only when debug was enabled. Serializing an object to yaml is an expensive operation especially when you need to scale up to thousands of calls per second.

(As reference, I am using java 8 with slf4j-1.7.25)

If I had directly used

 log.debug("The message is:{}", toYamlString(myObject));

then the message generating method would be called every time even if debug as disabled on the logger. This is because of the java argument evaluation mechanism.

The obvious choice here is:

if(log.isDebugEnabled()){
  log.debug("The message is:{}", toYamlString(myObject));
} 

but, apart of adding unpleasing code on top of your method, this is also doubling the call on if(log.isDebugEnabled()) that is also performed in the logging framework itself.So I took some time to see if it could be done in a better way.

At some point I found this post that was nicely solving this. I liked it and wrote my code accordingly. Then I realised it could be even simpler!

So I simplified it to only this:

  private static Object lazyString(final Supplier<?> stringSupplier) {
    return new Object() {
      @Override
      public String toString() {
        return String.valueOf(stringSupplier.get());
    }
  }

Then in my logging call:

  log.debug("The message is:{}",lazyString(() -> toYamlString(myObject)));

or, if your method take no arguments, you can use method reference:

  log.debug("The message is:{}",lazyString(this::toYamlString));

That's it! Simple and elegant.

The good news is that more and more logging frameworks added or are adding native support for deferred evaluation of arguments.

Until then we can use simple nice workarounds like this.

Have a nice day,

Dikran.

Tuesday, April 3, 2018

Compile Maven project and tests with different compilers and with different unit and integration test directories

My project is java, and I wanted to give my team the possibility to use java/junit and groovy/spock for our tests.

Moreover I wanted to keep unit tests separated from integration tests and if possible with different compilation life cycles so that the flow is:

1. compile the project code from src/main/java using the default compiler
2. compile and run the unit tests using the mixed java-groovy eclipse compiler
3. compile and run the integration tests using the mixed java-groovy eclipse compiler

This way the production code is compiled natively while we can play with java-groovy mixed classes in unit and integration tests.

After digging a lot and trying many unsuccessful approaches I got it working exactly as I wished.
Here is the pom:

As you may notice, I have left the unit tests in the standard maven path ie. src/test/java, but, if I want to further move them to src/test/unit/java then I need to configure both the compiler section and the surefire-plugin section in the same way I did for the integration tests.

Basically the secret in in instructing the compiler on:
- when to run (we configure this aspect within an execution section)
- where to compile sources from - within the element compilesourceroots
- where to output classes
- what classes (by name or pattern) to include - in the element outputDirectory
and at the same time to instruct the test runner (surefire or failsafe) on:
- where the test sources are located - within testSourceDirectory
- when the test classes are located - within testClassesDirectory

One essential thing to notice is the id of each execution element (in our case default-testCompile and integration-testCompile, because maven identifies each instance by it's id s it must be uniquely named.

Another thing that many don't know is that the ids can be overridden and indeed I have used the default maven compiler id for the unit test compilation so that only the eclipse compiler shall be run instead of runing also the default compiler. you can change the id and test yourself.

 Hope that shall help you too!

Cheers, Dikran

Friday, October 14, 2016

How to install docker on centos 6 - quick and dirty

Installing docker 1.12 on centos 6.8

While doing consultancy work at one big telecom company, I proposed introducing Docker in the process of automating and autoscaling parts of the software infrastructure, especially on the the java development chain and runtime deployment sides. They were enthusiastic about this so I got the task of making it happen. Just that at the time I did not know their infrastructure (all Centos 6.8) did not support docker...

Who got here must be quite desperate, as I got for a while after taking this task.
Lots of research and trial got me to put together the following instructions that made it work.

This is an unpolished, quick hand log of what I had to do in order to make docker successfully run on this OS version.

WARNING: Be sure of your deep linux understanding and knowledge before trying this into production systems!

Hopefully it shall help. I'll come back to this post time allowing, to better arrange, document and cleanup.

Cheers,
Dikran

Wednesday, March 30, 2016

Updating all branches from all local git projects in one shot


There are many times when I need to update at once more than just one git project.
I usually structure my projects under a common directory like /Users/Dikran/workspace/projects.
When I update I cd to the respective project and git pull.

I justs happens that recently I needed two things:
1) check updated code of more than one project.
2) check changes made on other branches than the current one.

As you know, git pull is updating only the current branch in a project. Moreover it has the following limitations (quoting from git-up project):

"It merges upstream changes by default, when it's really more polite to rebase over them, unless your collaborators enjoy a commit graph that looks like bedhead.
It only updates the branch you're currently on, which means git push will shout at you for being behind on branches you don't particularly care about right now."


So in order to solve those needs at once, there is a simple solution enabled by a simple script and a great git extension called git-up. This is a very convenient tool that does many nice things in completion to what git already offers. Check the site for docs and info.

The steps:

1. Install git-up extension
For Ruby (the original):
gem install git-up
Or for the Python port:
pip install git-up

2. Create a script (i.e. updateAll.sh) in the root directory of your git subprojects, containing the following:
#!/bin/bash

set -x

for project in */
  do git -C $project up &
done

wait
The script cycles through all subdirectories in the current directory, and issues background calls to git-up on every discovered directory.

The wait is added at the end so that the script shall exit only after all directory updating commands finished.

For a variation you can filter directory names if for instance you want updated only specific directories within a certain project. So for instance if you have your main project called myshop and the composing modules are myshop-frontend/ myshop-backend/ myshop-tests/ then just change the
for project in */
with
for project in myshop*/
Thats't all. Simple, isn't it?

A warning note though. Although git-up suits most cases, please check the documentation first, to be sure it won't mess things in your specific project's commit conventions.

Have a nice day,
Dikran

Tuesday, December 1, 2015

Automated Testing Aid: Manually Running a Quartz Job

I work in a project where testing is a first class citizen. We do unit tests, security tests, integration tests, end-to-ends api tests (SBE), and end-to-end functional (interface based) tests also by using SBE.
All right, everything's fine, until I need to throw in some asserts at the end of my integration/sbe test where I should check if the whole process performed well. Ok, only that this part of the process is accomplished by quartz jobs that run asynchronously in their specific setup, beyond our control.

Note: The assumption for this post is that your Quartz scheduler can be run within the same application with your tested classes. For distributed quartz jobs there is another story.

Some could say, ok, by you have the possibility to get a job by it's name and call triggerJob(JobKey) on a quartz scheduler instance, that should trigger the job immediately. But, be careful is about triggering a job, and not running the job. That means that:

  • the command is asynchronous and return immediately;
  • the job could actually start later, depending on the schedule's config and
  • you don't actually know when the job shall finish so that you can test your assumptions about the outcome of it.

Two quick solutions:
  1. after test's execution finished, before asserting on data, sleep the test thread for a while to give quartz time to do it's work. But sleep for how long? Some manual tries could give us some empirical idea of how long should we wait before the jos is usually executed, but we are never going to be 100% sure it actually was. And then, this approach could bring the execution of our test suite to last forever, imagine running hundreds of tests of this type that each are sleeping for few seconds... It doesn't sound very appealing.
  2. add a JobListener listener to the scheduler, then trigger the job and then put your main thread in wait until the listener is triggered on execution finished, and notifies your main thread so it can resume it's testing task. But, again, there might be many jobs already triggered and running until ours get's it's change to run. And after all, would you really want to get into unexpected threading issues? I think not.

So, after trying the aforementioned approaches and not really being happy with them I thought, why not directly run the jobs I am directly interested in?
Well this is not that trivial, because I'd like to run the jobs as they are, without having to know what other stuff is injected in each of my classes extending QuartzJob in order to make it work. So, after some research and study of how quartz works in collaboration with spring, that is what came out:


import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.Scheduler;
import org.springframework.beans.BeanWrapper;
import org.springframework.beans.BeansException;
import org.springframework.beans.MutablePropertyValues;
import org.springframework.beans.PropertyAccessorFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

import java.lang.reflect.Method;
import java.util.Map;

public class ManualJobExecutor implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public void executeJob(final Class<Job> jobClass) {

        try {
            //create job instance
            final Job quartzJob = jobClass.newInstance();
            // For the created job instance, search all services that are injected by quartz.
            // Those service instances are kept inside each scheduler context as a map
            final BeanWrapper beanWrapper = PropertyAccessorFactory.forBeanPropertyAccess(quartzJob);
            final MutablePropertyValues propertyValues = new MutablePropertyValues();
            //get all schedulers defined across all spring configurations for this application
            final Map<String, Scheduler> schedulers = applicationContext.getBeansOfType(Scheduler.class);
            for (final Scheduler scheduler : schedulers.values()) {
                // Populate the possible properties with service instances found
                propertyValues.addPropertyValues(scheduler.getContext());
            }
            //set the properties of the job (injected dependencies) with the matching services
            //the other services in the list that have no matching properties shall be ignored 
            beanWrapper.setPropertyValues(propertyValues, true);

            //get method executeInternal(JobExecutionContext) from job class extending QuartzJobBean 
            final Method executeJobMethod = quartzJob.getClass().getDeclaredMethod("executeInternal", (JobExecutionContext.class));
            executeJobMethod.setAccessible(true);
            //call the processItems method on the Job class instance
            executeJobMethod.invoke(quartzJob);
        } catch (final Exception e) {
            throw new RuntimeException(String.format("Exception while retrieving and executing job for name=%s", jobClass.getName()), e);
        }
    }

    @Override
    public void setApplicationContext(final ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

That's it!
Of course there are also other aspects, i.e checking if other job of the same class is already executing so that it won't overlap with your execution. Usually in Quarz, @DisableConcurrentExecution takes care of this but here you need to check it yourself.
You could also make your method accept a job by its name instead of class so you can get the names from your database instead of looking into project classes.

I hope this is going to ease your testing.
Please share your thoughts.


Have a nice day,
Dikran

Wednesday, May 27, 2015

Spring Boot & Jasypt easy: Keep your sensitive properties encrypted


Goal


I want to store my database password encrypted in the application properties file and provide the property encryption password at runtime as java system property or environment variable.

Context:


Java 7, Spring Boot 1.2.3.RELEASE
Currently Spring Boot does not offer native property encryption support.

Solution


Use jasypt encryption library and integrate it into Spring Boot's configuration flow.

How?
Here is a quick and dirty example:

1. Download jasypt and unzip the contents in a folder;
2. Choose a password for encrypting your sensitive properties; for the purpose of this example we choose "my-encryption-password";
3. Choose the property you want encrypted; here we choose to encrypt the database password "my-database-password";
4. Encrypt the database password ("my-database-password") using jasypt and the encryption password ("my-encryption-password"); go into the jasypt bin folder and run:

$ encrypt.sh  input=my-database-password password=my-encryption-password

----ENVIRONMENT-----------------

Runtime: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.60-b09

----ARGUMENTS-------------------

input: my-database-password

password: my-encryption-password

----OUTPUT----------------------

TJ1vA+DLWFrwEmbZKmGmawEonbJw4DxhkFf53JzKfvY=

The output is the encrypted password.
To configure the database in the SpringBoot's application.properties we add:

#for this example we use H2 database
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:my-schema
spring.datasource.username=test-user

#here we provide the database encrypted password by enclosing in ENC()
#so that jasypt can detect and decrypt it
spring.datasource.password=ENC(TJ1vA+DLWFrwEmbZKmGmawEonbJw4DxhkFf53JzKfvY=)


Integrating Spring Boot and Jasypt


In order to instruct Spring Boot to transparently interpret our property file and extract and decrypt the encrypted properties we need to:

1. Create a PropertySourceLoader implementation that knows how to parse property files, identify encrypted properties and decrypt them before making them available to other components. Also the class knows to get the encryption password from system properties (provided at command line by -Dproperty.encryption.password=my-encryption-password) or as an environment variable in the operating system (export PROPERTY_ENCRYPTION_PASSWORD="my-encryption-password"). Listing follows:
package com.myexample;

import org.jasypt.encryption.pbe.StandardPBEStringEncryptor;
import org.jasypt.spring31.properties.EncryptablePropertiesPropertySource;
import org.springframework.boot.env.PropertySourceLoader;
import org.springframework.core.PriorityOrdered;
import org.springframework.core.env.PropertySource;
import org.springframework.core.io.Resource;
import org.springframework.core.io.support.PropertiesLoaderUtils;

import java.io.IOException;
import java.util.Properties;


/**
 * This class is a replacement for the default Spring PropertySourceLoader. It has the capability of detecting
 * and decrypting encrypted properties via Jasypt Encryption Library.
 * The decryption password must be provided via an environment variable or via a System property. The name of the property can be {@code PROPERTY_ENCRYPTION_PASSWORD} or {@code property.encryption.password}.
 * For more information see http://www.jasypt.org/ and http://www.jasypt.org/spring31.html
 * For Spring Boot integration the default {@link PropertySourceLoader} configuration was overriden by
 * META-INF/spring.factories file.
 *
 * @see org.springframework.boot.env.PropertySourceLoader
 */

public class EncryptedPropertySourceLoader implements PropertySourceLoader, PriorityOrdered {

    private static final String ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_UNDERSCORE = "PROPERTY_ENCRYPTION_PASSWORD";
    private static final String ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_DOT = "property.encryption.password";
    private static final String ENCRYPTION_PASSWORD_NOT_SET = "ENCRYPTION_PASSWORD_NOT_SET";

    private final StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();

    public EncryptedPropertySourceLoader() {
        this.encryptor.setPassword(getPasswordFromEnvAndSystemProperties());
    }

    private String getPasswordFromEnvAndSystemProperties() {
        String password = System.getenv(ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_UNDERSCORE);
        if (password == null) {
            password = System.getenv(ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_DOT);
            if (password == null) {
                password = System.getProperty(ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_UNDERSCORE);
                if (password == null) {
                    password = System.getProperty(ENCRYPTION_PASSWORD_ENVIRONMENT_VAR_NAME_DOT);
                    if (password == null) {
                        password = ENCRYPTION_PASSWORD_NOT_SET;
                    }
                }
            }
        }
        return password;
    }

    @Override
    public String[] getFileExtensions() {
        return new String[]{"properties"};
    }

    @Override
    public PropertySource load(final String name, final Resource resource, final String profile) throws
            IOException {
        if (profile == null) {
            //load the properties
            final Properties props = PropertiesLoaderUtils.loadProperties(resource);

            if (!props.isEmpty()) {
                //create the encryptable properties property source
                return new EncryptablePropertiesPropertySource(name, props, this.encryptor);
            }
        }

        return null;
    }

    @Override
    public int getOrder() {
        return HIGHEST_PRECEDENCE;
    }
}

2. Create a com/myexample/META_INF/spring.factories file to override the default PropertyResurceLoader (org.springframework.boot.env.PropertiesPropertySourceLoader) which is provided with the Spring Boot distribution in META-INF/spring.factories. Our file should contain one line as follows:
org.springframework.boot.env.PropertySourceLoader=com.myexample.EncryptedPropertySourceLoader

That's it! Now your application should be able to use encrypted properties.

Thanks for reading!
Dikran

To give the right credits, info that helped me solving the problem and writing this post were gathered from this Stackoverflow post.


Friday, October 5, 2012

Scrum and Story Points, what's the story?

After working with scrum for a while and watching this debate of time vs story points I came to a personal conclusion that helped me to make better estimations and use the story points at their best value.

  In my opinion story points best measure risk. You estimate this risk taking into account your proficiency, overall experience and the expertise in the technology, the project and it's business, the dependencies involved that you need to rely on to move forward (could be external systems/teams, business analysts, other people availability) and your average capacity of solving problems in a given time.

  So when it comes to estimating a user story you should ask yourself: “what is the risk of this story?” I would categorize the risk vs story points as follows:

1 point - Virtually no risk, insignificant work doable in a very short time

3 points - Extremely low risk, know all about it can do it quickly, probably a matter of 1-2 hours

5 points - Low risk, know most about what I need to do, probably can fit in few hours to one working day

8 points - Medium risk, know quite well about what I need to do, I might have some unexpected obstacles and maybe some dependencies on other (external) resources, but I am confident I can do it in 1-3 days.

13 points - High risk, there are aspects about I have no idea on how to tackle, have external dependencies about that I am worried, it might take half of a sprint to get it done.

21 points - Highest risk, I have right now no knowledge about the subject and no idea of how to do it, there are lots of dependencies on other (external) resources that I cannot manage, I am not sure I can solve it in a sprint so that story becomes demoable. Then you should ask yourself: is this really a good story or rather an epic? Shouldn't  it better go into a research spike first so that we gather more knowledge about how to do it?

However, when you estimate always take into consideration collateral aspects such as unit/functional/integration test writing (that can take as much or more than time need to code functionality), team communication, code reviews and other things that should be part of your development process.

What do you think?

Cheers,
Dikran.