Archive

Archive for the ‘iPROFS’ Category

AngularJS: A checkbox with radio button behavior

Did you ever needed to have a group of option in which just one item could be selected, but the user did need to have the option to deselect any chosen option in HTML?

It can’t be done just by HTML checkboxes or radio buttons and the user experience of a select with options isn’t sufficient.

We did have to provide such a solution in a recent project.

Read more…

Book review and Summary: Switch

Have you ever tried to change something? In (part of) an organisation, or maybe in yourself? How successful was it? How did you accomplish this feat?

According to this great little book called Switch, you most probably have addressed three significant areas: the rationale, the emotion, and the environment. The authors Dan and Chip Heath call these: the Rider, the Elephant, and the Path.

Read more…

Global Day of Coderetreat 2012 at iPROFS

On the 8th of December I participated  in the Global Day of Coderetreat 2012. I attended the one that was organized by two colleagues Bart Bakker and Marco Beelen at the iPROFS office in Haarlem. This event focuses on the fundamentals of software development and design by intense practicing.

Read more…

Categories: iPROFS, Java Tags:

Code Retreat

The Sunday after the SCNA conference a code retreat was held at 3 locations in Chicago. I attended the one at the 8th Light office, hosted by Corey Haines.

Code retreats are really awesome! With global day being in a week from now I like to tell a little about code retreats and why you want to join us on global day. Read more…

Categories: iPROFS Tags: ,

Continuous Delivery workshop

On Saturday September 15, I attended a free workshop about continuous delivery by Robert Chatley, in Amsterdam. This workshop was organized by Ugly Duckling.

Continuous delivery is most about getting feedback much faster than with traditional (i.e. conservative) delivery strategies. Traditionally releasing is error-prone and time consuming, and often quite stressful. Teams and project managers want to release as few times as possible because it is so hard. The agile mindset teaches that if something is this hard you should it more often (practice it) so that you get better at it. Continuous delivery adopts this mindset and is about removing the bottlenecks from the delivery process, so that you can deliver in minutes rather than hours (or sometimes even days), at any time. Read more…

Categories: iPROFS

Mock liferay services in unit tests for 6.1.1

Using mock Liferay 6.1.1 services in a unit test.

When you are developing components, which interact with Liferay services, you will want / need to use mocks for those services.
In previous versions of Liferay the best strategy for this was to use the LocalServiceUtils in your production code and provide the mocks by setting that mockLocalService on an instance of the LocalServiceUtil.

For instance: To use a mocked GroupLocalService you needed to do the following in your test setup:

GroupLocalServiceUtil groupLocalServiceUtil = new GroupLocalServiceUtil();
groupLocalServiceUtil.setService(mockGroupLocalService);

Read more…

Categories: iPROFS, Liferay Tags: , ,

Building web services with haste

A few weeks ago a customer needed two web services. One of them needed to return an image, the other some data in XML document form. The contract of these services didn’t really matter. And of course, haste was required. They had other companies who wanted to start their integration with these services. Read more…

Categories: iPROFS

Life’s not about frameworks

Last week I came across a post on Java Code Geeks about how “ORM haters don’t get it”. The author rambles on about how the arguments of the so-called haters are wrong, and he explains his understanding of ORM and how he claims that without using ORM from the start, every project eventually ends up with a home-grown ORM-like framework.

I don’t place myself in a group of ORM haters, and frankly I have to agree with the author that a lot of bashing against ORM is going on lately. Partly this is because other, more simple, techniques became available to interact with the database, such as the Active Record. Another reason is the trend of using NoSQL over relational databases. Read more…

Categories: iPROFS, Java Tags: ,

Devnology Community Day Review

16/04/2012 Leave a comment

This year I had finally convinced my partner to join me for the Devnology community day, convincing him that there would be several other C# programmers there. So we set out early, braving the slippery roads (which didn’t turn out all that bad). We arrived just after the building was supposed to be open. Which would have been great if it wasn’t for the fact that it was in fact still closed. There was quite a crowd standing before the gates already. But as it was -15 degrees Celcius, we decided to stay in the car under the emergency blankets we had brought. After about forty minutes, somebody with a key showed up and we went inside. I didn’t take off my coat until after I’d finished my first cup of tea. And so the day started about fifteen minutes late.

How to show code quality – Joost Visser

The session started out well with an open discussion, trying to find out what quality is. According to Joost there are two kinds of quality: funtionality and technical quality. Whereas functional quality (the code does what was specified) is relatively easy to point out, technical quality is less tangible. This lead to a discussion on what makes code beautiful. Some aspects that were pointed out are easy to understand, performance, loosely coupled code, code split according to responsibilities, and compliance to coding standards, to name a few.

Read more…

Patching open-source java software with Maven

16/04/2012 1 comment

As soon as you start using third party libraries in your project, you also introduce all the bugs in those libraries into your project.

There are various ways to handle these kinds of situations:

  • Sometimes you won’t even notice the bugs being present, when you don’t use that section of the library.
  • When you do notice a bug, you can upgrade to newer version of the library in which the bug was already fixed.
  • You might create a work-around in your code.
  • Or you could patch the third-party library.

Sometimes the patch already is present in the trunk of the project, but no newer release is made yet. Encouraging a release-early, release-ofter strategy sometimes work to get a stable release without the bug being present, but it’s good to have alternatives. Most likely you aren’t a committer on the project of the library, so you become dependend on other developers, which could create problems for your deadlines.

This procedure in this post will describe a way to create a stable patched released version of the third party library in your own software repository.

In this post I will use the recaptcha4j library as the example of the software to patch. The only available released version of that library is net.tanesha.recaptcha4j:recaptcha4j:0.0.7. The code in this library still references the server URL’s on https://api-secure.recaptcha.net instead of the newer https://www.google.com/recaptcha/api. Since the names in the SSL certificates won’t match various browsers will show warnings or won’t work at all on the old URL’s. So the task at hand is to create a patched version of the library, which will use the new URL’s.

One way of doing this is copying the entire project into your own source code management tool, make the changes and release software. I prefer to keep the original software as seperate as possible from my own changes. So my way of doing this is:

  1. Create a maven project for the patched version.
  2. Extracting the original classes out of the third party library during a maven build cycle.
  3. Replace the classes, which need to be patched by custom versions.
  4. Create a new jar-file containing the combination of original and patched classes.

Note: Of course I use some naming convention to prevent version conflict between the original software and the patched version.

Create a maven project for the patched version.

Of course you need a project location in your own source code management tool and create the default maven project structure with a pom.xml.

To identify the patched version of the library I use the groupId and artifactId of the original library, so everybody will still recognize dependency on the third party library. Within the version of I add an extra version-digit plus a describtion of the patched.
In our example it would become:

  <groupId>net.tanesha.recaptcha4j</groupId>
  <artifactId>recaptcha4j</artifactId>
  <version>0.0.7.1-iprofs-https-patched-SNAPSHOT</version>

Within this pom I add a dependency to the original ‘broken’ version of the third party library. This will add all classes and dependencies to the classpath of my project enabling my IDE to use those classes during the build.

  <dependency>
    <groupId>net.tanesha.recaptcha4j</groupId>
    <artifactId>recaptcha4j</artifactId>
    <version>${original.recaptcha4j.version}</version>
    <type>jar</type>
  </dependency>

Extracting the original classes

During the build I use the maven-dependency-plugin to extract the classes from the original version to the target build location. This will ensure all classes will become part of the new patched jar-file. You need to exclude all broken classes from extraction, because your patched versions will not become part of the jar-file if the originals are already present in the target location.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>unpack</id>
      <phase>generate-sources</phase>
	<goals>
	  <goal>unpack</goal>
	</goals>
	<configuration>
	  <artifactItems>
	    <artifactItem>
		<groupId>net.tanesha.recaptcha4j</groupId>
		<artifactId>recaptcha4j</artifactId>
		<version>${original.recaptcha4j.version}</version>
		<type>jar</type>
		<overWrite>true</overWrite>
		<outputDirectory>${project.build.directory}/classes</outputDirectory>
		<excludes>
		  **/ReCaptchaImpl.class,**/ReCaptchaFactory.class
		</excludes>
	    </artifactItem>
	  </artifactItems>
	</configuration>
     </execution>
   </executions>
 </plugin>

Replace the classes, which need to be patched by custom versions.

Within my project I create the same package structure and classes for all classes, which need to be patched.
Extracting them from a source jar is a very good way to get started or copy them from the libraries version control system.
In my example it would be net.tanesha.recaptcha.ReCaptchaImpl.

Create the patched jar-file.

For this step you don’t need to do anything special. If you properly excluded the patched classes the maven build process will extract and compile all classes to the proper locations and the maven-jar-plugin will build your patched jar-file. Using your normal maven release process you are now able to create a patched stable release version and deploy it into your own software repository.

Tricky situations.

After using this procedure to create a patched version of the recaptha library and redeploying the software I still noticed that references to the old server URL’s were being used. The cause of this weird behaviour was a compiler optimalization called ‘Constant folding‘. ‘Constant folding’ is the proces of replacing all references to or calculations of constants values by the final constant value in the byte code of the compiled classes.

Within the recaptcha library the ReCaptchaFactory references the constants defined in the ReCaptchaImpl. In the original class file for the ReCapthcaFactory the values still were the server URL’s which we needed to patch in the first place. Therefor the exclusions in the dependency extraction does contain that Factory as well.

Recommendations.

Contribute back to the original project.

If you went through all this trouble to fix a bug in an open source library, it is recommended that you create a patch of your changes and submit those to the open source project. Many project welcome such contributions and you get to make the world a better place for everybody.

Monitor releases for the original project.

Subscribe to the release mailing list of the original project and monitor their future releases. As soon as the provided a release, which incorporated your patch, switch to using the normal orginal library again.

Categories: iPROFS
Follow

Get every new post delivered to your Inbox.

Join 205 other followers