Only Software matters

Experiences in software development

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 638 other followers

  • MVB

  • JavaCodeGeeks

    Java Code Geeks

  • My recent tweets

Archive for the ‘java’ Category

Agile ALM Book Review

Posted by Patroklos Papapetrou on December 26, 2013

Some time ago I was looking for some resources around the Internet in order to combine the agile principles we were already following with a more flexible application lifecycle management. I wanted to find ideas and methods to get the best out of developers’ practices with source code infrastructure and well-known and mature tools that cover all development phases. I was so lucky that I found the Agile ALM book by Michael Hüttermann. I really enjoyed reading it and applying its concepts to real projects and I wanted a long time ago to write a review about it. Now, during Christmas time, it was the best period to do it, so here it is.

The initial paragraph of the “Preface” section summarizes the author’s intent:

Welcome to Agile ALM. This book has three main goals. The first is to describe Agile
Application Lifecycle Management (ALM) in practical terms and to provide a plan for
rolling out Agile strategies and best-of-breed tools. The second purpose is to explain
how to create ALM toolboxes based on standard tools used in advanced, real-world
cases. The third goal is to give you some guidance on how to choose the best tools, use
them correctly, and integrate them while applying Agile strategies. These three goals
are the focus of this book.

The author of Agile ALM bookMichael Hüttermannand is a Community Leader an Oracle Java Champion at, the Chairman at Java User Group Cologne a freelancer and delivery engineer that helps companies with SCM/ALM, Agile, Continuous Delivery and DevOps.

The title of the topic and the table of contents were the key factors that made me (I assume this is true for other readers) read it from the very early during MEAP program offered by Manning. The topics are suitable for both junior and experienced software developers. Delivery engineers will find it very useful as well even if they have no previous experience with the concepts introduced in the book. The Agile ALM is divided into four multi-chapter parts.

Part 1 (“Introduction to Agile ALM”) introduces  the basic concepts and building blocks of an agile ALM with practical use cases and best strategies. Chapter 1(“Getting started with Agile ALM”) sets the roots by discussing the evolution of ALM and how the use of lightweight tools can boost the effectiveness of an ALM through a real-life example. Chapter 2(“Agile and ALM strategies”) starts by explaining how project management can fit in an agile environment and propose a series of strategies to implement ALM processes. The remainder of the second chapter is about finding a balance between over-controlling the ALM and not controlling it at all.

Part 2 (“Functional Agile ALM”) touches the concepts of release management and task-based development in a higher, non-technical level. Chapter 3(“Using SCRUM for release management”), as its title implies is all about SCRUM and how practitioners can apply release management using SCRUM principles. Readers, after finishing this chapter, whey will be able to implement, following a detailed step-by-step guide, a release management process. The Subversion supporting strategies that finish third chapter are the bonus included topic. Chapter 4(“Task-based development”) talks about a series of mature tools such as Jira, Trac, Bamboo and others that facilitate task-based development, bug tracking and project management.

Part 3 (“Integration and Release management”) is considered more technical as it describes techniques using a variety of tools to manage and release artifacts and apply continuous integration. Chapter 5 introduces the Maven  ecosystem and explains the process of releasing using some of the most well-known Maven features. After reading this chapter you will be able to do release management with Maven and get the foundation ideas for the rest of the chapters. Chapter 6(“Creating a productive development environment”) discusses Mockito and its important role in mocking, stubbing and isolating systems during test execution. This chapter, also, teaches us the art of creating and maintaining workspace environments for developing, integrating and testing software systems.  The rest of the chapter deals with various advanced continuous integration techniques. Although there are plenty of great books for each topic discussed in this chapter, what makes it special is that everything is placed in the context of agile ALM. Readers, especially those that have already a small experience with such processes will find it really useful to see all these well-established tools fitting in their development lifecycle.

The last Part 4 (“Outside-in and barrier-free development”) of the book moves agile ALM even further by introducing some approaches for requirements and test management. What is really cool, is that, again, in chapter 8(“requirements and test management”) these concepts are presented with practical advice and examples using testing frameworks such as Selenium, TestNG, FitNesse and others. The topic of collaborative tests was one of my favorites throughout the book. Not only it’s perfectly explained but it made me also realize how testing processes and should be considered and implemented. The last, but not least, chapter of the book (“Collaborative and barrier-free development with Groovy and Scala”) explains how it’s more productive to use different languages for development and testing activities (polyglot programming). Spock, easyb and spec2 are some of the tools presented in this chapter to describe using practical examples the concepts of Business Driven Development (BDD) and Domain Specific Languages (DSL)

Conclusion : The Agile ALM book is not just another “agile” book. The high expectations set when reading the abstract and the back page of the book were met. One might think that the large number of techniques and tools included in the book might annoy or confuse the readers but this is not happening because as already said, everything is discussed withing the context of ALM. You will learn a lot of new ideas and strategies and you will be able to adopt them immediately. Even if you’re not familiar with some of them, the book explains very nice the basics and moves directly to the approach that will solve a particular problem in the development lifecycle.

Posted in agile, book review, java, jenkins, software | Leave a Comment »

Fixing common Java security code violations in Sonar

Posted by Patroklos Papapetrou on September 21, 2012

This article aims to show you how to quickly fix the most common java security code violations. It assumes that you are familiar with the concept of code rules and violations and how Sonar reports on them. However, if you haven’t heard these terms before then you might take a look at Sonar Concepts or the forthcoming book about Sonar for a more detailed explanation.

To get an idea, during Sonar analysis, your project is scanned by many tools to ensure that the source code conforms  with the rules you’ve created in your quality profile. Whenever a rule is violated… well a violation is raised. With Sonar you can track these violations with violations drilldown view or in the source code editor. There are hundreds of rules, categorized based on their importance. Ill try, in future posts, to cover as many as I can but for now let’s take a look at some common security rules / violations. There are two pairs of rules (all of them are ranked as critical in Sonar ) we are going to examine right now.

1. Array is Stored Directly ( PMD ) and Method returns internal array ( PMD )

These violations appear in the cases when an internal Array is stored or returned directly from a method. The following example illustrates a simple class that violates these rules.

public class CalendarYear {
 private String[] months;
 public String[] getMonths() {
    return months;    
 public void setMonths(String[] months) {
    this.months = months;

To eliminate them you have to clone the Array before storing / returning it as shown in the following class implementation, so noone can modify or get the original data of your class but only a copy of them.

public class CalendarYear {
 private String[] months;
 public String[] getMonths() {
    return months.clone();    
 public void setMonths(String[] months) {
    this.months = months.clone();

2. Nonconstant string passed to execute method on an SQL statement (findbugs) and A prepared statement is generated from a nonconstant String (findbugs)

Both rules are related to database access when using JDBC libraries. Generally there are two ways to execute an SQL Commants via JDBC connection : Statement and PreparedStatement. There is a lot of discussion about pros and cons but it’s out of the scope of this post. Let’s see how the first violation is raised based on the following source code snippet.

Statement stmt = conn.createStatement();
String sqlCommand = "Select * FROM customers WHERE name = '" + custName + "'";

You’ve already noticed that the sqlcommand parameter passed to execute method is dynamically created during run-time which is not acceptable by this rule. Similar situations causes the second violation.

String sqlCommand = "insert into customers (id, name)  values (?, ?)";
Statement stmt = conn.prepareStatement(sqlCommand);

You can overcome this problems with three different ways. You can either use StringBuilder or String.format method to create the values of the string variables. If applicable you can define the SQL Commands as Constant in class declaration, but it’s only for the case where the SQL command is not required to be changed in runtime. Let’s re-write the first code snippet using StringBuilder

Statement stmt = conn.createStatement();
stmt.execute(new StringBuilder("Select FROM customers WHERE name = '").

and using String.format

Statement stmt = conn.createStatement();
String sqlCommand = String.format("Select * from customers where name = '%s'", custName);

For the second example you can just declare the sqlCommand as following

private static final SQLCOMMAND = insert into customers (id, name)  values (?, ?)";

There are more security rules such as the blocker Hardcoded constant database password but I assume that nobody is still hardcodes passwords in source code files…

In following articles I’m going to show you how to adhere to performance and bad practice rules. Until then I’m waiting for your comments or suggestions.

Posted in java, quality, software, sonar | Tagged: , , , | 10 Comments »

20 +2 Subjects Every Software Engineer Should Know … and the books you need

Posted by Patroklos Papapetrou on July 19, 2012

I recently read an extremely interesting and useful article about the 20 subjects that every software engineer should know or learn….
What is really cool is that it’s not restricted to products, languages but it describes generally accpepted technologies, methodologies and practices.
It applies both to  junior and exeperienced software engineers. The former have a guideline about the fields that need to focus whereas the latter have the chance to re-evaluate their knowledge.
What’s missing, IMHO, is to give the reader a clue about which are the best book(s) related to these subjects so in this post I give my advices on that. Of course the list of books is not complete and it’s just my opinion based on my experience.

Hope you find it useful as well!

1. Object oriented analysis & design

2. Software quality factors

3. Data structures & algorithms: Basic data structures like array, list, stack, tree, map, set etc. and useful algorithms are vital for software development. Their logical structure should be known.
6. Software processes and metrics
8. Operating systems basics
10. Network basics
13. Dependency management
15. ORM (Object relational mapping)
18. Internationalization (i18n)

Posted in agile, cdi, ci, continuous integration, java, quality, software, sonar, testing | 10 Comments »

Creating composite JSF components

Posted by Dimitra Konstantinidou on August 30, 2011

A composite component is a component that consists of other components and it can be reused with a minimal effort. JSF 2.0 simplifies the creation of custom components.

In this post, we describe the steps in creating a simple composite custom component with child components using JSF 2.0. We also show how we can pass methods and event listeners as attributes to a custom composite component.

1. We create a .xhtml page that consists of two main sections: a) the section where the attributes of the component are declared and b) the implementation of the component. For example:

<html xmlns=""

<composite:interface componentType="customComponent">
<composite:attribute name="id" required="true"/>
<composite:attribute name="columns" required="false" default="4"/>
<composite:attribute name="columnClasses" required="false" default="labelColumn,dataColumn,labelColumn,dataColumn"/>

<h:panelGrid id="#{}_panel" columns="#{cc.attrs.columns}" width="100%" columnClasses="#{cc.attrs.columnClasses}" >
<h:outputLabel value="#{general['label']}:"/>


2. For each attribute of the component we specify a name, whether it is required or not, and possibly a default value. Thus, the above component has three attributes (id, columns and columnClasses) one of which is required (id), while for the remaining two we define default values. As a result, the columns attribute has the value 4, unless a different value is specified in the page where the component is used.

In the section where the implementation of the component is defined (composite: implementation) we refer to its attributes using expressions of the form: cc.attrs.AttributeName.

The element <composite:insertChildren/> places any child components declared within the composite component tag in the using page, at the specified point within the <composite:implementation> section. This element can be used only once within the <composite:implementation> section.

3. We create a new folder named components inside the folder resources of a .war file or alternatively in the folder META-INF/resources of a .jar file. We place the above page (customComponent.xhtml) in the folder components.

4. In order to use the component in a .xhtml page at first we specify the url of the library to which it belongs:

the part notifies JSF that this is a custom component that consists of other JSF components. The second part /components has the same name with the name of the folder where the implementation page of the component is stored.

We then insert a statement like the following:

<e:customComponent id="componentId" >
    <h:outputLabel value="Child component/>
</e:customComponent>                                                                   or

<e:customComponent id="componentId" />

where the name of the component is the same as the name of the page defining its implementation (customComponent.xhtml in our case).

Attributes that correspond to simple methods

In order to set a method as an attribute of a composite component, we do the following:
a. In the attributes section of the component we insert a statement like this:
<composite:attribute name="handleChanges" method-signature="void handleChanges(Object)" required="false"/>

In the definition of the method signature we can use any name for the method.

b. In the implementation section of the component we use the above attribute like this:

<p:ajax event="change" listener="#{cc.attrs.handleChanges}" update="#{}_panel" />

Attributes that correspond to JSF event listeners

(The described workaround is based on the following post

In order to set a method that is an event listener, as an attribute of the composite component, we work as follows:
a. In the attributes section of the component we insert a statement like the following:
<composite:attribute name="handleChanges" method-signature="void handleChanges(org.primefaces.event.SelectEvent)" />

b. We create a Java class (CustomComponent) which inherits from the base class UIComponentBase (or another class that represents a JSF component ) and also implements the interface javax.faces.component.NamingContainer. The annotation @FacesComponent results in the automatic registration of the class CustomComponent with the JSF runtime as a UIComponent.

The value attribute corresponds to the name of the component.

@FacesComponent(value = "customComponent")

public class CustomComponent extends UIComponentBase implements NamingContainer {


public String getFamily() {

return "javax.faces.NamingContainer";


public void handleChanges(SelectEvent event) {

FacesContext context = FacesContext.getCurrentInstance();

MethodExpression handleChanges = (MethodExpression) getAttributes().get("handleChanges"); (1)
handleChanges.invoke(context.getELContext(), new Object[]{event}); (2)



The class CustomComponent contains one method which: gets the attribute of the component that contains the declaration of the listener method (1) and then
calls the listener passing the appropriate number of parameters (2).

c. On the implementation page of the component, at first we specify the type of the component as customComponent:
<composite:interface componentType="customComponent">

<composite:attribute name="id" required="true"/>

Then, with a statement like the following we define that each time an item is selected from the list of the primefaces’s autocomplete component, the method handleChanges is called, which in turn calls the listener that is passed as an attribute to our component.


<p:ajax event="itemSelect" listener="#{cc.handleChanges}" update="#{}_panel"/>


d. In order to use the component on a .xhtml page , we insert a statement like the following:

<e:customComponent handleChanges="#{handler.handleSelectionChanges}" id="componentId" />

The method handleSelectionChanges is defined as follows:

public void handleSelectionChanges(SelectEvent event)



Posted in java, jsf, software | 3 Comments »

Why there is no standard for developing real modular web applications?

Posted by Patroklos Papapetrou on July 19, 2011

OSGI, SpringSource, Jboss Modules,J2EE and the list never ends.All these technologies promise to their end users/developers the same thing which is more or less java modular web applications(?). How many of us out there, though, have actually tried to develop a REAL modular software system in Java? How many of us have managed to get it done? You have probably noticed that I have capitalized the word real and this is not done accidentally. I shortly explain what I mean by the definition:”real modular java system”.

IMHO a REAL software module should be able to have parts for at least business logic, persistence, user interface and configuration. A software module, in an ideal scenario, should be able to be plugged-in and plugged-off easily in a running application without restarting it.  For example in a J2EE application server ( such as Jboss or GlassFish) the running application (core system) is a .war file. Some more modules (that contain parts mentioned above) of the core system are developed and packaged in separate jar files. These jar files shoule be deployed in the application server, integrated with the core system (by some extension points in business logic AND in User Interface ) without the need of re-deploying it. Can we do something like this?

Let’s see what related technologies suggest about it. I was a fan of JBoss Modules since their first steps, and after the recent latest release of JBoss AS I was looking forward to see them in action. To be honest JBoss modules provide a very simple and convenient way to define dependencies between modules. Oops!! Did I write “modules”? What kind of modules are these? They can include business logic, configuration, data model but what about user interface? Unfortunately nothing is mentioned about that and after a little research, I have found that the concept of modularity in JBoss modules does not include any user interface. What about OSGI? The most promising way of building moduar applications. OSGI is nowadays supported from many application servers and although its configuration looks like dinosaurs in the age of industrial revolution seems to be a very nice approach. Plenty of available services, a dozen of frameworks to use and of course no reference to any user interface capabilities. On the other hand there is vaadin that integrates(?) well with OSGI to build modular web applications, as the relevant article implies. I wonder if there is a real/productive modular enterprise application developed with OSGI and Vaadin. Spring is an independent framework by SpringSource which is currently the leader in developing java enterprise applications. Spring Dynamic Modules in conjuction with OSGI claim to be the most sophisticated way to build dynamic and modular web applications, but again I still feel that even Spring is not solving the problem I have raised. From my researching experience integration of the above technologies for a modular system is a hard task. Last but not least comes J2EE. The latest version of web and full profile specifications have transformed J2EE to a very powerful set of frameworks. JSF2 and CDI as well as with all the new features have dramatically increased its popularity among Java developers. When I read for the first time this article, I believed that finally I have found a standard solution for modular web applications.  Although each jar can contain all different parts: business logic with EJB and CDI , persistence with JPA and its implementations, configuration and user interface with JSF and its implementations ) according to this issue there is no way to handle jars with JSF components as a separate module. One more dissapointment. Modules in J2EE are supposed to be jars packaged in a single war. That was too close!! We have to wait, I guess, until the release of JSF 2.2 and some months later for support of the most well-known application servers.

Since there is no standard for building modular systems, many well-known projects, have developed their own module system based on one of the previous mentioned frameworks or from the scratch. Jenkins, Atlassian’s Jira and Sonar by SonarSource are all java based applications with a powerful module / plugin system. You develop your plugin (including user interface), following some guidelines and you deploy it as a single jar through a module/plugin manager. In most cases you need to restart the system but I think that this does not bother any administrator since you can easily increase the functionality of your software.

So my dilemma is still valid. Should I start building my own module / plugin system or should I wait for a standard to come and boost the developing of modular web applications worldwide? I wonder why this kind of standardization is not yet available and why we are obligated to try-catch-finally ( still without resources 🙂 ) among all these technologies and frameworks! Are we close to have a standard for developing real modular enterprise web applications or not?

Thanks for reading my thoughts and I am looking forward for your comments

Posted in java, software | Tagged: , , | 17 Comments »

%d bloggers like this: