miércoles, abril 20, 2011

Are You Locked Up In A World That's Been Planned Out For You? Are You Feeling Like A Social Tool Without A Use? (She - Green Day)



From JBehave site: JBehave is a framework for Behaviour-Driven Development (BDD). JBehave allows developers, QA and non-technical or business participants, to write stories in a plain text file with minimal restrictions about grammar. Then a POJO is created for executing created story. This POJO should have the typical BDD structure Given, When and Then.

From Springsource site: Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure so you can focus on your application.

From Selenium site: Selenium is a suite of tools to automate web app testing across many platforms.


We have three technologies JBehave for acceptance tests, Selenium for web application testing and Spring dealing with infrastructure. In this post I will talk about integrating JBehave with Selenium 2 and Spring.

For this example I have created a very simple web application using Spring MVC. I know that business logic is not accurate to the reality, but it is simple enough to illustrate how to integrate all these technologies together.


I have divided this post in three main subsections:

  • Integrating JBehave with Spring. There is no web application here, only business logic.
  • Integrating Spring MVC with Selenium 2. Only to show how easy is implementing automated tests with Selenium 2.
  • Integrating JBehave with Selenium 2. Web application used in previous example but instead of using only Selenium for automating testing, JBehave instructs to Selenium which steps should execute.
Application that I will use is a simple TraderService, (explained in JBehave page (http://jbehave.org/reference/stable/)). This TraderService generates Stocks, and if a Stock is traded below threshold, its alert status is OFF and if it is traded above, alert status is ON.

In this tutorial I assume that you have a basic idea of JBehave and Spring.


  • Integrating JBehave with Spring:

In this case no web GUI is used, we are going to use JBehave for writing acceptance tests of business logic.

Basic classes are:
  • TradingService, that defines a method for creating stocks. TradingServiceImpl is the implementation.
  • Stock, that contains stock information and logic about its status.
  • StockAlertStatus is Stock status Enum.

Acceptance test part:

First of all we should create a story. A story is where stakeholders, developers... should say what they want the application do, and which are the expected results for given parameters. In our case a story has been created for validating that alarm is OFF if trade value is under threshold, and ON otherwise.


The important parts of that file are: Scenario for describing what we are testing, all symbols between <> that are used as variables, and Examples that are values injected to previous "<>" variables. In this story file two examples are provided, so two executions will be produced, one for each row. As final note, Given, When, Then words should be placed at start and are reserved words, also more than one Given, When or Then could be used in each story.

Next step, create a class that transforms a story written in "natural language" to code. We could say that this class is equivalent of creating a junit class; In JBehave these classes are called Steps. Because we are integrating with Spring an annotation called Steps is created. This annotation extends from Component annotation so Spring component-scan can wire up step classes too.


And Steps annotation is used in TradingServiceSteps class.


In TradingServiceSteps is where all magic occurs. This class is responsible of transforming story file to an execution. Let's see:

@Steps because we want Spring creates automatically this bean. TradingService is the business logic we want to test, and is injected using Autowire annotation. And finally one method for each Given, When, Then. Explained quickly, when JBehave finds an @Given, it searches into loaded stories for a phrase starting with Given. After that checks if @Given string value matches the Given definition expressed in story file. If matches then inject the story parameters as method parameters, for example STK1 as string parameter, or 5 as double threshold parameter. Moreover, in this case because we are using Examples in our story file, @Named annotation for each parameter is required. The named parameters allow the parameters to be injected using the table row values with the corresponding header name. Each parameter is converted from String to required parameter type.

We have written stories, and how to execute them (TradingServiceSteps class). JBehave requires another class, that will be responsible of configurating it. Basically you should configure Step classes and story files location, and what kind of reports are generated.

In our case, because we are integrating JBehave with Spring, some information is provided using Spring Injection.


This class is where JBehave is configured and is responsible for running all stories. Let's examine the most important lines:

In line 1 we specify a JUnit runner for running JBehave stories with Spring.
In line 2 we are configuring JBehave with Enum parameter converter, see that StockAlertStatus is an enum, because it is not a primitive parameter, a converter should be provided. JBehave comes with some convertes, but we can implement ours too.
In line 3 the embedder that we will use. This is the standard embedder for JBehave. Embedder represents an entry point to all of JBehave's functionality that is embeddable into other launchers.
And finally with @UsingSpring we are providing two Spring files, one where step classes are defined, and the other one where JBehave is configured.

Configuration file is a standard Spring file injecting required JBehave parameters:


This is a generic configuration file, that I use in all projects. You configure the output, the classloader for Embedder and prefix for parameters

And finally a Spring context file where all step classes are defined. And you know what, thanks of Spring this is as simple as:



No magic, remember that each Step class has an @Steps annotation? Thanks of component-scan, you don't have to define each Step class in @UsingSteps annotation or using tags.

Now run previous class as JUnit, and reports with results are generated.


  • Integrating Spring MVC with Selenium 2

Selenium 2 is a suite of tools to automate web app testing across many platforms. In this case WebDriver approach has been used. WebDriver is an interface for automating tests in a programmatic way. Selenium provides several implementations depending on browser where tests are run.

For this example I have created an Spring MVC application, that are composed of two pages, one form where all stock information is provided and a page where status of inserted stock is showed. Of course Spring MVC controller for managing all information is also implemented.

Controller of this small application is:


showForm method is used for showing the form where user will write stock information. submitForm method is called when submit button is pushed, and creates an stock and send to showstatus page the status of stock.

StockForm is simply a class with three attributes (stock, threshold and tradeAt price). No secret here.

Form page is also so simply but I will show it because form information will be used for configuring Selenium:



Page for showing status:


WebDriver is used in JUnit test for automatizing a sequence of events. In this case, the sequence will create an stock below threshold and assert that response page shows that alert status is OFF.



Most important sections of previous JSP are:

JSP taglibs <form:input path=""/> like <form:input path="name"/> in form, and <div id="result">. These fields are important because they are used by Selenium for filling form and asserting showed status.

For example, in Selenium class:

WebElement name = driver.findElement(id("name")) returns a "reference" to <input id="name" type="text"> element and using sendKeys method, you are sending keyboard chars to that component.

WebElement element = driver.findElement(id("result")), returns a "reference" to div element and using
assertThat(element.getText(), is(StockAlertStatus.OFF.name())); getText method, none tag characters of element are returned.

Now running this test is as simple as running TraderIsAlertedSelenium class as a simple JUnit test class. When running this class a browser (Firefox in this case) will be opened, and all programmed interactions will be executed on your screen.

At this point we just have to join both previous parts, and integration between JBehave with Spring and Selenium will be reality.


  • Integrating JBehave with Selenium 2 and Spring

JBehave has a module called JBehave-Web, that is used for integrating JBehave with web pages. Base classes are WebDriverProvider and WebDriverPage. Both classes are used by JBehave for abstracting from browser, and also for providing common methods to test webpages. In this example I won't use jbehave-web for two reasons, first because Selenium 2 with WebDriver offers a level of abstraction that is enough for this example, and secondly because WebDriverPage is a class that implements some common funcionalities for testing, but it is abstract, I don't like using extension only for sharing common operations between classes, it is a bad practice (not discussed here), I prefer aggregation. So in this case I have preferred  implementing my class for implementing common functionalities.


In this case abstraction from browser is acquired using WebDriver (Selenium) interface. Moreover all common operations are implemented into this class. The idea of this class is to be used in several projects and for that reason a better design should be desired, but for current example is enough.

Next group of classes are those that use PageUtils object. I have created one class for each page that Selenium should interact with. Acts as a facade to web.

For example class for dealing with page containing form to insert new stock is:


Three operations can be executed in this page, the first one is open the page. Because "insert a new stock" is accessed manually (in this case is the front page), an open method is provided with URL. Also a method for filling stock form and and another for submitting it are provided.

And finally a class that transforms an story written in "natural language" to code (also known as Steps class), this class would be the same used in first example (TradingServiceSteps) but adapted for dealing with web pages (using previous classes).


See that there is no differences between this class and the one created in first example, but using web page interfaces instead of business objects. 

Next modified files are:

Story file:


that has been modified to use web terminology.

Spring file:


that injects into TradingServiceWebSteps required beans.

Configuration file used in first example is the same, and Spring file for configuring JBehave is the same too.

In summary I can definitely say that integrating JBehave with Selenium 2 and Spring is not a difficult task, compared with the benefits that lead us having an automated acceptance test platform. I wish you have found this post useful.

Download Full Code

viernes, abril 15, 2011

Everywhere I'm Looking Now I'm Surrounded By Your Embrace Baby I Can See Your Halo You Know You Are My Saving Grace (Halo - Beyonce)

Spring Security provides comprehensive security services for J2EE-based enterprise software applications. 

There are two important concepts in application security.  

  • Authentication is the process of establishing a principal is who they claim to be, generally that information comes in form of username/password.
  • Authorization refers to the process of deciding whether a user is allowed to perform an action within your application.

In Spring Security, and as summary, we can say that two classes are responsible of implementing each concept:

  • Main interface for Authentication is AuthenticationManager. The default implementation is ProviderManager. This rather than handling request itself, it delegates it to a list of AuthenticationProviders which each one tries to perform the authentication against its back-end with username and password provided. An example of providers is DaoAuthenticationProvider, LdapAuthenticationProvider...
  • Main interface for Authorization is AccessDecisionManager. Spring Security includes several AccessDecisionManager implementations that are based on voting. Three AccessDecisionManagers are provided: AffirmativeBase (grants access if any voter returns an affirmative response), ConsensusBased ("Consensus" here means majority-rule (ignoring abstains) rather than unanimous agreement (ignoring abstains)), and UnanimousBase (requires all voters to abstain or grant access). In fact voters are the most important concept of authorization process, because are the final responsible of granting or not access to a resource.

Imagine next problem, you have developed a website for an online television, where only during daylight programs are live broadcasted and recorded, and during night programs recorded during day are rebroadcasted. Because of bandwidth problem, only registered users with ROLE_USER can watch live programs, but the rest of the world (registered or not) can watch at night the programs recorded during the day.

There are many approaches for developing that requirement, but how about implementing a voter that votes affirmative when it is night and negative when it is day?


See that most important method is vote. This method receives the caller invoking method, the secured object and the configuration attributes associated with the method being invoked and only returns if it grants, if it denies or if it abstains access to resource. Because our requirements are as easy as comparing if it is day or night these attributes are not used.

And I suppose you are wondering, "Ok man so easy, but how I register this new voter to the AccessDecisionManagers object?". Well it is also easy, the only inconvenience is that namespaces does not provide this feature and beans should be configured as old-school spring security files.


At line 1 we are configuring the security to http calls as usually but instead of relying on default decision manager, we are referencing to an access decision defined below.

At line 5, an AffirmativeBased decision manager is created, with two voters, one that will grant access if user have required role (line 8) and another one that is NightVoter implemented above granting only access if it is night.

And finally Authentication Manager beans with inmemory approach.

I think is a clean solution of an authorization problem, and also shows how Spring Security can adapt to very different scenarios involving web security.

domingo, abril 10, 2011

Another Shot Of Whiskey Can't Stop Looking At The Door Wishing You'd Come Sweeping In The Way You Did Before (Lady Antebellum - Need You Now)



With new release of JDK 7, a lot of really useful features has been developed, some of them I have write off before in this blog (JSR 203 and JSR 166y). In this post I am going to talk about one new small enhancement. This new feature is the addition of java.util.Objects class. This class is similar to java.util.Arrays or java.util.Collections but for objects instead of arrays or collections

This class offers nine methods grouped by four groups: equality, hashing, nullables, and toString. Let's examine all of them.

  • compare(T a, T b, Comparator c):int => Returns 0 if the arguments are identical and c.compare(a, b) otherwise. Consequently, if both arguments are null 0 is returned.
  • deepEquals(Object a, Object b):boolean => Returns true if the arguments are deeply equal to each other and false otherwise. Two null values are deeply equal. If both arguments are arrays, the algorithm in Arrays.deepEquals is used to determine equality. Otherwise, equality is determined by using the equals method of the first argument. This operation is useful if you want to compare two objects and you don't know exactly if Object is a "single" object or an array. This method manages this problem, and compares both instances correctly.
  • equals(Object a, Object b):boolean => Returns true if the arguments are equal to each other and false otherwise. Consequently, if both arguments are null, true is returned and if exactly one argument is null, false is returned. Otherwise, equality is determined by using the equals method of the first argument. And I suppose you are wondering "nice but I have an equals method in object class". Yes you are right but look next example:
If foo is null, a NullPointerException is thrown. One can argue that you should check for null input parameters, this is a simple example, but I am sure all of us sometimes we have received a NullPointerException in an equals.

But see that:

Not And a Half is showed instead of throwing a NullPointerException.

  • hash(Object... values):int => Generates a hash code for a sequence of input values. The hash code is generated as if all the input values were placed into an array, and that array were hashed by calling Arrays.hashCode(Object[]). This method is really useful in DTO objects. For example Hibernate "requires" that all objects implement equals and hashCode. It is typical that DTOs can contain lot of fields, take a look any of these classes how many lines of code can contain those hashCode methods. But see how simple is using this method:

  • hashCode(Object o):int => Returns the hash code of a non-null argument and 0 for a null argument.
  • requireNonNull(T obj):T => Checks that the specified object reference is not null. This method is designed primarily for doing parameter validation in methods and constructors. If obj variable is null a NullPointerException is thrown. Look next example:
I think it is a clean solution, avoid noise code, and it is more readable than if(foo == null) throw new NullPointerException();

  • requireNonNull(T obj, String message): T => Checks that the specified object reference is not null and throws a customized NullPointerException using message parameter, if it is.
  • toString(Object o): String => Returns the result of calling toString for a non-null argument and "null" for a null argument.
  • toString(Object o, String nullDefault): String => Returns the result of calling toString on the first argument if the first argument is not null and returns the second argument otherwise. I find this method so useful for logging porpoises. Sometimes you are going to log some information that null value has a meaning. For example without using this class, a log line could be:
But would be more readable:

I am sure java.util.Objects would not go down in history as the best new feature added in JDK 7, but honestly, I find it so useful and it will help me so much developing code even more readable. Enjoy it.

jueves, abril 07, 2011

Come On Let's Twist Again Like We Did Last Summer Yea, Let's Twist Again Like We Did Last Year (Chubby Checker - Let's Twist Again)




JPA 2 Criteria API allows criteria queries to be constructed in a strongly-typed manner, using meta-model objects to provide type safety. This is a useful feature because when a change occurs in database, for example a rename of a field, your queries will not compile, and you will see the problem in compilation time instead of running time.

Yes I have already talked about in my previous post http://alexsotob.blogspot.com/2011/01/deep-inside-you-cry-cry-cry-dont-let.html but there are an API that do the same as Criteria API, and is called QueryDSL. QueryDSL is a framework which enables the construction of type-safe SQL-like queries for multiple back-ends including JPA, JDO and SQL in Java. Working with QueryDSL and JPA is like working with HibernateMetamodel Generator because QueryDSL has an Annotation Processor that generates Meta-model information from JPA 2 annotated classes. So I suppose you are wondering, why I should use QueryDSL instead of JPA 2 Criteria API? In its site there are interesting posts about that http://source.mysema.com/forum/mvnforum/viewthread_thread,49.

What makes really different QueryDSL from JPA2 Criteria API, is that QueryDSL also works with JDBC applications. Yes you read it right, JDBC applications can take benefit from QueryDSL, and instead of creating queries as plain text, they can be constructed in a strongly-typed manner too.

Some of advantages of using QueryDSL in JDBC are:
  • Code Completion in IDE.
  • Almost no syntactically invalid queries allowed (type-safe on all levels).
  • Domain types and properties can be referenced safely (no Strings involved!).
  • Incremental query definition is easier.

If you visit its webpage you could see one example using QueryDSL with JPA, but also one for JDBC. What I am going to explain is how to use QueryDSL with Spring Jdbc Template. Most of us, when we develop a Spring application and want to use JDBC, we use JdbcTemplate class or one of its extensions.  For that reason I will explain how I use JdbcTemplate with QueryDSL.

First of all I implement an extension of JdbcTemplate class. I have called QueryDSLJdbcTemplate. This class has a simple method called queryForList(SQLQuery sqlQuery, RowMapper rowMapper, Expression... expressions) and has three parameters, the first one is a SQLQuery object, this is the main class where you define the query you want to execute (like JPA 2 Criteria), the next one is a RowMapper object as most of JdbcTemplate methods use, and the third one is an array of Expressions; these expressions represents each database fields we want to return as result, like id, name, age, ....

Implementation of this method:


At line 4, we are attaching a connection to given SQLQuery.
At line 6, the query is executed, and result set is returned.
At line 10, the result set is transformed to a list of required objects, using RowMapper.

Next step is creating a query. In this example I will use an Employee class that have two attributes, an id and a name. The query is finding an employee by name. So EmployeeDAO looks like:


Using JPA you specify which database engine is used injecting Database dialect. In our case it is a JDBC application so we should configure SQLQuery object with database engine used, so QueryDSL generates query syntax correctly. This is done with line 1 and 2.

Line 4 is an auto-generated class, similar to classes generated by Hibernate Annotation Processor. It contains all meta-information of an entity.

Line 5 is the query construction. See that we are not creating an SQL string (SELECT * FROM Employee as emp WHERE emp.name=?), but we are creating in a programmatic way. Look this line qEmployee.name.eq(name) because if we change field name to fullName, our code will not compile (qEmployee.name attribute does not exist now) meanwhile SQL string approach will compile, but crashing in runtime.

Line 7 is a simple RowMapper, and there the parameter name is also not specified as string but as an object, where native queries were rs.getString("name") and if name does not exists an SQLExpcetion was thrown, now a compilation error would be thrown too.

After RowMapper definition, we are executing the find method. The last two attributes are the fields we are looking for. Between SQL query and QueryDSL expression you can identify the FROM clause in both and the WHERE clause in both, but not the * of SELECT. This is the place where this information is passed.

Last method is for extracting real column name to result set.

Of course this is a basic implementation, for example Dialect should be injected rather than created each time, EmployeeRowMapper could not be an inner class, and getParameterName should be in a Util class, but because of clarity, all this code has been implemented in the same class.

And I suppose you are still wondering what is QEmployee class. Employee class is a simple DTO object. QEmployee is where all meta-information of Employee class is stored. In JPA usually JPA Providers have an Annotation Provider that read annotated model classes and generates Meta-model classes. In JDBC, there are no annotated model classes, but an alternative mechanism is provided for generating these classes. QueryDSL provides an ANT-task, a Maven-Task, and a Plain API. I will show you plain API configuration and same values should be provided for ANT and Maven tasks.


You must specify as input parameters, a connection to database and which schema contains business model. And as output parameters, which package should be generated meta-model classes, and root source code directory. The best approach for generating these classes is using Maven, so before compile goal is executed, all meta-data model is generated.

And Spring Application Context class looks as simple as:


Now you can take all benefits from using DSL for queries in JDBC applications.

viernes, abril 01, 2011

'Cos The Only Thing Misplaced Was Direction And I Found Direction There Is No Childhood's End (Childhoods End - Marillion)




JSR 203 is a new specification implemented in JDK 7, and is about NIO 2.0. JSR 203 defines three points of improvement:
  • Filesystem interface.
  • Complete Socket-Channel Functionality.
  • Support for Asynchronous I/O.

In this post I will talk about filesystem interface, because there are new classes that implements some file functionalities that more often than not I had developed myself in projects. In summary we will take a look to Path class and Files class.

Path is "an object that may be used to locate a file in a file system. It will typically represent a system dependent file path". Well in common language a path is the route to a resource. More or less like old File class, in fact java.io.File has a new method toPath() that returns a Path instance.

Files class is an utility class that implements common file operations like creating, finding (you say finding? yes), deleting, reading contents ...

For me typical operations that are implemented in Files class are:

* Delete a file (/tmp/test/sec.txt)

Path file = Paths.get("/tmp/test", "sec.txt");
Files.delete(file);

Files.delete method deleates passed file path, and that's important because with not empty directory a DirectoryNotEmptyException is thrown.

And how about deleting a directory with contents? let me introduce another new concept. FileVisitor interface. Files class has a method for walking along all directories tree. This is useful if you wanted for example implements the tree *nix command (prints all directory structure for given root directory). But in my case I will implement a complete delete function (*nix equivalent command would be rm -Rf /tmp/test).



Previous code is equivalent to command rm -Rf /tmp/test. SimpleFileVisitor is an implementation of FileVisitor. It implements default behavior for all FileVisitor methods, and in this case we override visitFile for deleting files. After all files of current directory are visited postVisitDirectory method is called and current directory can be deleted safetly. See that the result in this case is CONTINUE (continuing walking through tree, but as you can imagine you have other options like SKIP_SIBLINGS, SKIP_SUBTREE or TERMINATE).


* Copy a File

Files class has three main methods for copying files. It is important to note that you can copy files and directories, however files inside the directory are not copied, so the new directory is emptied even when the original directory contains files. 

Files.copy(source, target, REPLACE_EXISTING);

Moreover two methods are also present for copying files. Files.copy(InputStream, Path, CopyOptions...) and Files.copy(Path, OutputStream). As you can imagine first method takes an inputstream and copy its content into given Path, and the second one, reads given Path and sends file content to passed outputstream.

Same is applied for Files.move(Path, Path, CopyOption...).

For copying all directory structure with their files, a FileVisitor could be implemented as in previous example.


* Manage Metadata Information

Two main classes are created for managing files metadata. One class for reading metadata attributes like permissions, is hidden, is read-only, owner, modified-time, ... Because each OS manages file attributes in different manner, an implementation of that class are provided for each OS. For example there is an implementation for DOS systems, another one for POSIX systems, or even a helper class for implemting yourself attributes reader.

Posix example for printing group which belongs given Path:


The other class is FileStore. A FileStore represents a storage pool, device, partition, volume, concrete file system or other implementation specific means of file storage. This class is used for calculating disk usage.



* Reading, Writing, Random Access

Files class has methods for creating inputstreams, outputstream, readers, channels, ... because this features are not new I won't explain extensively. For example for acquiring an InputStream instance Files.newInputStream, Files.newOutputStream, ...

* Symbolic and Hard Link

With NIO 2.0 you can create a symbolic link http://en.wikipedia.org/wiki/Symbolic_link or a hard link http://en.wikipedia.org/wiki/Hard_link from a path.

Creating a symbolic link to a directory:



Creating a hard link to a file:



* Finding Files

Sometimes my programs should find all files with extension xml contained in a directory and manage them (for example create a zip with them). Before java NIO 2, a FileFilter was created and then create a matcher for only selecting those with xml extension. Now PathMatcher class can be used instead of creating yourself matcher. This matcher accepts Glob Syntax http://en.wikipedia.org/wiki/Glob_(programming) or Regular Expression. Glob syntax is easy to use and flexible and most of us have been used  (in console operations) although we didn't know it was Glob Syntax.

Let's implement the next *nix script ls -R *.html in java.



As you can see this implementation of FileVisitor follows all directories structure finding all html files. See that there are two important lines:

matcher = FileSystems.getDefault().getPathMatcher("glob:*.html");

where we are creating a matcher that only returns true if file ends with html.

if (name != null && matcher.matches(name))

that returns true if current file matches the the glob condition.

Thanks of FileVisitor and PathMatcher this routine can be reused for any kind of files (modifying glob expression). Think now if you should do the same with java.io.File class, you would create a FileFilter where if you wanted to create a flexible solution you should create a Pattern Matcher, iterate over matches, and deal with recursive navigation through directory tree. See with PathMatcher how easy is changing between selecting all files ending with html extension to selecting all files starting with word 'Test'.

* Watcher Service

This new feature is really useful for receiving events when a directory has been changed by creation, modification or deletion of a file. Before NIO 2.0 you should create an "infinite-loop" that was watching if a new file was created. And this was done listening all files and comparing modification date or comparing with previous loop execution. Now this service automatizes all logic, and simply throws an event when registered change occurs.



Two final notes, first is that events are only thrown for files not for directories, and second one, watch service is not recursive, so it will only throws an event in case of files created into /tmp not /tmp/my-directory. As with all java NIO 2.0 you have FileVisitor interface for dealing with recursive directory tree.


* Determine MIME Type

If your application requires to know MIME type, Files class  has a probeContentType. The implementation of this method is highly platform specific and is not infallible.

Path path = Paths.get("/tmp/dataset.xml"); System.out.println(Files.probeContentType(path));

It returns text/xml.


And those are all new features of NIO 2 that have changed my developer life when I have to develop an application where managing files are required. I wish you find them as usually as I do.