Software Technology Geek

JAVA SE 7 has been released, what about JAVA SE 8

2011-09-07T21:00:00.002+02:00

Simon Ritter gave a talk about the further development of the JAVA platform at JavaZone 2011 in Oslo. In this blog entry I will try to recap the main aspects of his presentation titled Moving Java Forward: Java SE 7 has been released, what about Java SE 8? and give some additional information where it seems feasible.

Review in the History of Java

JAVA has been started as a project at SUN led by James Gosling back in 1992. The outcome was a compact basis for writing applets which slowly evolved into one of the most widely used programming platforms.

In 1998 the platform made a first major step away from being only a programming and execution environment for applets and swing applications. Back then SUN released version 1.1.2 - named JAVA 2.

Then came 2004 and the announcement of JAVA 5 which finally paved the way into the enterprise platform market. A large set of bitterly missed features were added like generics or annotations.

The next major release (JAVA 6) opened the JVM for scripting languages and provided some management and monitoring features.

On 28th of July 2011 Oracle announced the latest version so far: JAVA 7. It contains features like:

* Parts of Project Coin (strings in switch statements, underscores in binary int literals)
* NIO.2 (I/O improvement towards enhanced platform independence)
* Fork/Join Framework (flexible and reusable synchronization barriers)

Oracle acquired SUN - mission changed?

Since Oracle acquired SUN in January 2010, a lot of rumors and news were spread: positive and negative ones. Unfortunately, this as well as the fact that employees needed to re-position themselves within the new context led to a smaller break in the development of the language. But fortunately Oracle seems to have an open ear to the community and its customers and finally identified four major aspects to follow:

* grow the developer base
* grow the platform adoption
* increase the platform competitiveness
* adapt to change

Beside that, they decided not to have the different stacks (JAVA SE, JAVA EE and JAVA ME) maintained separately but to combine all efforts in one committee in order to reflect that there is just one language.

Although the company committed itself to the adoption of new ideas, this does not imply that they support the incorporation of all suggestions made by users. The overall goal concerning the implementation of language enhancements and new features is code readability. In his talk, Simon Ritter made a nice side blow towards Perl.

Up to now it sounds like if Oracle is trying to get in charge on decisions made whether a feature will be added to the next release or not. But, as Simon Ritter argued in his talk, Oracle will stick to the java community process. However, they will slightly change it to meet the fusion of the three different language stacks: JAVA SE, JAVA EE and JAVA ME. In the end there is one committee which reflects the fact that there is only one language.

Besides work concerning the language itself there is an ongoing process covering the consolidation of the two runtime environments living within the same company: Hotspot and JRockit, where Hotspot is used as source enhanced by JRockit features.

JAVA SE 7 is out, what’s up to JAVA SE 8

So far I have just talked about the history and what happened when Oracle acquired SUN last year. Now I will give some hints on what’s coming next for JAVA 8, which is planned to be released in October 2012.

Maybe I am wrong but from what I have heard and read so far, I would say that JAVA 8 promotes in large parts features that will enhance the multi-core support and bring new language features supporting the programming model required for these types of hardware architectures.

Lambda expressions in parallel collections
A good point to start from is the sorting of collections. Actually it can be done in a serialized way by simply stepping through its contents using a simple for-loop. In JAVA 8 there will be parallel collections having a special filter method the progammer has to provide a predicate to. Filtering will be done with the best hardware utilization as possible. Beside that the collections will have a map function to filter out those attributes the caller is really interested in.

Since JAVA 8 will bring lambda expressions to the platform, these can be used for the filtering purpose as well like:

cars.filter( #{Car c -> c.seats == 2} ).map( #{Car c -> c.age} ).max();
(returns the max. age of all cars having just two seats)

Think about how much code you need to implement this feature using inner classes.

Single Abstract Method Classes
The concept of single abstract method (SAM) classes will make it easier to write inner classes having only one single method. Actually Runnable#run or Comparator#compare are examples of SAMs.

Today we write the following:

car.dummyMethod( new Runnable() { public void run(System.out.println(c.seats));});

Using lambda expressions combined with SAM, we can do the same thing as follows:

car.dummyMethod ( #{Car c -> System.out.println(c.seats)} );

But we will need to follow a set of rules to leverage SAM classes and lambda expressions at their best:

1. Lambda expressions are applicable only in a context where they could be converted into SAM types (eg Runnable, Comparator, Callable, EventHandler):
Object test = #{ 123 } is not allowed
2. Lambda expressions must not have any break or continue statements. Their return type is inferred from the overall set of return statements within the expression.
3. The variable this has the same value as it would have outside the statement.
4. Variables accessed from lambda expressions must not be modified (should be final).

Extension methods
The main idea behind extension methods is the evolvement of APIs without breaking the backwards compatibility. Neal Gafter has written a nice blog entry about this: http://gafter.blogspot.com/2007/11/closures-prototype-update-and-extension.html
At the core of if it, an interface which is extended after it has been made publicly available provides a static standard implementation of the new method(s). All classes implementing the interface and do not provide code for the new method will the standard implementation automatically.

Value classes
Writing DTOs or value classes is one of the most time consuming tasks producing nothing else than classes having some attributes with their associated getter and setter methods. The concept of value classes tries to provide a simple solution where those attributes accessed via getter and setter methods are marked with a special keyword property, ie:

class Node { Node property parent; Node property leftChild; Node propert rightChild; }

Collection literals
Collection literals will solve a common problem when filling lists, sets or maps on creation with pre-defined data. Today this works a follows:

List digits = Collections.unmodifiableList(Arrays.asList([1,2,3]);

The new approach simplifies this:

List digits = [1,2,3];
Map namedDigits = { 1 : “one”, 2 : “two”, 3 : “three” };

module-info.java
I am trying to write a good introduction to this the fourth time right now thus I am just showing the layout of the named file proposed in Simon Ritters talk:

module com.mnxfst.product @ 1.0 {
requires jdom @ 1.0;
requires rome @ 1.0;
class org.openjdk.aggregator.Main;
}

The goal is not just to get rid of the classpath option but also to give the runtime environment sufficient information on how to run the named application correctly. Therefore only those library versions will be used that the developer named in module-info.

Profiles and Modules
The idea behind profiles and modules is to have a single language platform where you choose appropriate components from to support a certain context, eg. enterprise or mobile. In JAVA 8 this is promoted through Project Jigsaw.

Conclusion

Although most of the things I wrote about the upcoming JAVA 8 release are not quite new, I love to see how precise they got by now. Therefore I would like to dedicate the last paragraph to an evaluation of the listed topics:

Oracle acquired Sun
I hope that Oracle will stick to the JAVA community process and keep the platform as free and accessible as possible.

Lambda expressions
Although lambda expressions look a bit different from the java code we currently know, I expect them to improve the language a lot. Not only that they reduce the lines of written code but also make it more readable.

Single Abstract Methods
The same that applies to lambda expressions is also valid for SAMs: they will reduce the written code and make the remaining lines more readable.

Value Classes
In the age of code generators and other neat little helpers, I do not see a real use case for value classes beside the fact that they definitely will reduce the written code. Although I am a bit skeptical, I can say for sure that I will use them if they are available since it spares me to execute the code generator.

Collection Literals
On first sight I was a bit excited about this feature since it makes it really easy to create and fill a collection, list or map on creation. But then they reminded me about the problems I had with the auto (un)boxing feature that moved in with JAVA 5 (int i = list.get(0) might exit with a NPE).
Unfortunately I expect to see the same problems again thus this feature - although really nice and time saving - is not what I was waiting for.

module-info
Since Simon Ritter did not talk too exhaustivly about this feature I am not sure how it will work in practice. Let’s assume an application requires commons-logging 1.0 and a component used by the application requires commons-logging 2.0, how will this work without any troubles? If you’ve got any suggestions or information, please let me know since I am eager to learn about it.
After all I think this is a nice enhancement cleaning up the classpath a bit.

Profiles and Modules
Personally, I have never understood why there are three different type of JAVA specs: SE, EE and ME. Providing a common platform which can be extended concerning its installation footprint according to a specific profile seems to be reasonable. Therefore I must say that I am excited about this.

Getting Primeface and JSF EL to work on Google App Engine

2011-08-27T00:26:00.000+02:00

Lately I decided to use the Google cloud infrastructure as runtime foundation for a new project. At least two reasons led to a positive decision towards Google's App Engine: (1) a very strict but straight development paradigm and (2) the availability of a free quota.

Since I need to get some presentable results quickly and did not want to spend precious time learning a new ui framework, I chose to try out the availability of JSF 2.0 on GAE in interaction with Primefaces. Fortunately I stumbled across an article by Derek Berube on how to setup Primefaces in a GAE environment.

Unfortunately I ran into two small but annoying errors that kept me away from making any progress for a while. The first one appeared everytime I requested a JSF page:

java.lang.UnsupportedOperationException
at javax.faces.context.FacesContext.getCurrentPhaseId(FacesContext.java:660)
at javax.faces.event.ExceptionQueuedEventContext.(ExceptionQueuedEventContext.java:158)
at javax.faces.event.ExceptionQueuedEventContext.(ExceptionQueuedEventContext.java:106)

I could get rid of it by replacing the recommended Mojarra version 2.0.4 by 2.0.3.

The second problem is associated with SUNs implementation of the expression language. So, I replaced it by the JBoss implementation but had to make changes to get it working, since it breaks the law of not spawning any threads. Therefore I copied the modified contents of org.jboss.el.util.ReferenceCache
into the source folder of my project.

Finally I got my project using Primefaces 2.2.1 and JBoss-EL 2.0.1 working.

Concurrency and Performance (Intro)

2011-03-10T20:54:00.003+01:00

In my last blog articles, which are unfortunately more than 4 months old, I wrote about an application I developed during my spare time. Lately I began
to migrate mshop from Spring 3 to JEE 6 for some reasons I may talk about in an upcoming article.

During the refactoring, I came across certain concurrency and performance topics which puzzled me for some time. In parallel a colleague of mine established a company interal workshop series about current software development topics. Since I do think that concurrency and performance are two fundamental topics in software engineering, I offered to prepare a little series about these subjects. As these presentations contain no company secrets, I decided to present them at this place as well. If you have got any ideas or topics you would like to read about, do not hesitate to contact me.

In order to make you aware of the subjects to come, I will present you a typical concurrency situation producing invalid data. Let's assume we have two actors A and B where both share a common bank account BA they try to withdraw money from. To map this into a software I used a very naive approach and modeled a bank account implementation as follows:

/**
* Provides an unsafe bank account implementation
*/
public class UnsafeBankAccount {

private int amount = 0;

/**
* Initializes the account
* @param initialAmount
*/
public UnsafeBankAccount(int initialAmount) {
this.amount = initialAmount;
}

/**
* Withdraws a named amount of money from the account. In
* case the withdrawal is allowed the method returns true
* otherwise false
* @param a
* @return
*/
public boolean withdrawMoney(int a) {

if(a < amount) {
amount = amount - a;
return true;
}

return false;
}

/**
* Returns the current amount of money stored
* in this account
* @return
*/
public int getAmount() {
return amount;
}

}

In a single-threaded environment this implementation would cause no trouble since it is accessed in a sequential manner. If you tend to use the UnsafeBankAccount in a multi-threaded setting, you might observe inconsistent states between the results of UnsafeBankAccount#withdrawMoney and UnsafeBankAccount#getAmount.

Assume the following situation: the actors A and B share a common bank account BA they wish to withdraw money from. At first each checks the current state of the account calling UnsafeBankAccount#getAmount and then decide to withdraw a certain amount of money without overchecking the account. What could happen is:

The initial amount of BA is $100

A checks the account and sees that the account holds $100

A orders to withdraw $30 from the account

While the software validates the condition of the if-clause in UnsafeBankAccount#withdrawMoney to true the scheduler interrupts the computation and hands over the control to the thread of B

B checks the account as well and also sees that the account holds $100

B orders to withdraw $80 from the account

The execution thread handling the order of B as well validates the if-clause in UnsafeBankAccount#withdrawMoney to true, recalculates the current state of the account and returns true

Now the execution thread handling the order of A also recalculates the current state of the account and returns true as well

If any of the customers checks BA, they will see that the account is overchecked by $10

A different situation could be:

The initial amount of BA is $100

A orders to withdraw $30 from the account

Before UnsafeBankAccount#withdrawMoney has the chance to update the variable amount, the scheduler interrupts the current thread

Now B checks the current account state by calling UnsafeBankAccount#getAmount and sees that the account still holds $100

To ensure that the bank account works as expected in both cases, we need to ensure that (1) the amount variable is always in a consistent state and (2) each call returning the amount sees the most current value.
The magic element in this case is the synchronized modifier which will be used to guard the reading and writing accesses to amount. This leads to the following modification:

/**
* Provides a thread-safe implementation of a bank account
*/
public class ThreadSafeBankAccount {

private Integer amount = null;

/**
* Initializes the account
* @param intialAmount
*/
public ThreadSafeBankAccount(int intialAmount) {
this.amount = Integer.valueOf(intialAmount);
}

/**
* Withdraws a named amount of money from the account. In
* case the withdrawal is allowed the method returns true
* otherwise false
* @param a
* @return
*/
public boolean withdrawMoney(int a) {

synchronized(amount) {
if(a < amount) {
amount = amount - a;
return true;
}

return false;
}
}

/**
* Returns the current amount of money stored
* in this account
* @return
*/
public int getAmount() {
synchronized(amount) {
return amount;
}
}

}

The implementation above ensures that no read or write access takes place while another thread reads or writes the amount variable. Depending on the use case mapped by the implementation, the synchronisation used in the getter method could be omitted, eg. the caller does not wish to retrieve the latest and most current value.

mShop - Screenshots

2010-10-18T17:56:00.014+02:00

It's been a while (again) since I provided you with information about the current state of affairs concerning the mshop implementation. Today I would like to present some screenshots and detailed information about how I implemented the features I presented in my last post (eg. object class hierarchy definition and alike).

Creating attribute types

Object class definitions within the application consist of an unique name and a set of attributes. Each ettribute has its own value type like STRING, INTEGER or TIMESTAMP. Assigning these atomic values types directly would strip down the possibility to have a differentiated handling per attribute. Take an object class person having attributes firstname and lastname both of type STRING for example. When an user approves the order of an instance of type person the application could not handle the values of firstname and lastname in different ways but as every STRING in the context. The reason is that attribute names are just free text values having no impact on the processing.

In order to remove that limitation, mshop introduces own attribute types where each type is assigned a concrete value type like STRING or INTEGER. Take the example above. We would create an attribute type FIRSTNAME of value type STRING and maybe a type BIRTHDAY of value type TIMESTAMP. This gives the user the option to modify the handling of approved instances according the attribute types, eg combining the values of types FIRSTNAME and LASTNAME to a value givenName that is provided to a ldap server.

Creating object class orders

The driving force behind mshop are user defined object classes which serve as blueprints for concrete object instances (eg. class com.mnxfst.blog.Person is the defining type for instance Christian Kreutzfeldt). Therefore you need to define classes before your users are able to order instances of those types.

Creating an object class requires you to provide some more detailed information and must be carried out with a certain amount of care since it is the foundation of the later running system.

The definition dialog has three different tabs. The first tab lets you provide common information about the class like its name, if it is an abstract class, the activation date or the set of attributes.

The second tab lets you specify detailed information on how certain object class instances will behave in the approval workflow. You can define for each configuration (attribute value setting) the required audit level (how many people must approve the order) and what kind of operations are allowed for specific value settings.

The attached screenshot shows a configuration where object instances of the ordered type which are referencing the city of Hamburg and the specific street Kehrwieder need to be approved by two people for the operations create, update and delete.

These settings alone do not configure the concrete workflow path afterwards but represent the building bricks for it. In case an user orders an instance of type Person the application checks the attribute value settings and matches them against the associated workflow configuration in order to look up the required audit level.

The third tab finally lets you define approvers for ordered object class instances. Compared to the second tab, this one behaves nearly the same but adds another field: priority level. The audit level defines on which approval level the named user is provided with an workflow item for a specific order. The priority level gives you the opportunity to define proxy rules in case a named approver does not answer within a defined timespan.

Approving object class order

After having fully specified an object class, it needs to be approved by at least one object class approver. The object class approver opens the dialog displayed below and chooses to view all open/unanswered object class orders. In order to have the chance to validate the object class configuration he is allowed to browse through all the settings the originator made. The handling and behavior is quite straight forward and needs only little description.

Order object class instance

In case an object class has been approved its available to all users which are allowed to order instances of that type. The screenshot down below shows a set of classes the user can choose from.

The next step shows a set of available parent classes the user can choose from to define a hierarchy.

The third step lets the user specify values for the assigned attributes. The last step finally sends the object class instance order into the workflow process.

Approve order object class instance

The final view I would like to present today is the dialog for approving object class instance orders. Each approver is presented a list of all orders that he is allowed to approve / reject. By selecting a single workflow item he is able to see all required order details like common information (audit level, priority level, object class name and alike) and the attribute value settings.

Actually most of the dialogs do not look very fancy and colorful but I will try to improve on that until the first release of the application.

mShop - The object classes

2010-06-30T21:34:00.002+02:00

It's been a while since I wrote my last post about the mshop application. Today I would like to present the
data structure which is visible to the application user and offers him the ability to model his problem domain
as best as possible.

As I have stated in my last article, most applications leave you with a rather inflexible data structure which
requires you either to adopt your problem domain to the software system or modify the software system in its
core parts to support your problem domain. Neither way is an acceptable solution to your problem.

When I started to design the mshop application, I had in mind that establishing a kind of a centralized order process
within a company must adhere to the fact that the users are not willing to use one service for ordering objects
of type A (like user accounts) and another service for ordering objects of type B (like computers or other office
supplies). Beside that the whole workflow based approval process needs to be independent from the concrete object
types handled by the system.

Therefore I tried to define a very generic data structure and a highly flexible approval engine. Both elements
will be presented more detailed in the following paragraphs.

Data structure

The data structure basically follows the object oriented design techniques used for software component specification. The following types are provided

attributes

attribute types (like integer, date ...)

classes

objects (as class instances)

A class is composed of an arbitrary number of attributes which have a specific type which could be a

INTEGER

DECIMAL

STRING

TIMESTAMP

BOOLEAN

BLOB

OBJECT_REFERENCE

CUSTOM_TABLE_REFERENCE

Most of these types are self-explanatory except OBJECT_REFERENCE and CUSTOM_TABLE_REFERENCE. An attribute
of type OBJECT_REFERENCE is allowed not to hold a value but a reference to another object (eg. a user references
another user to model the supervisor relationship). This gives the user the maximum power to model complex relationships.

The other special type (CUSTOM_TABLE_REFERENCE) has been implemented but is not in use. The idea behind this attribute type is the ability to reference objects or values that are completely unknown to the application and must not be modeled
within the domain. Actually this is just an extension point that might be used in the future.

When an attribute is assigned to a class, the user needs to specify some attribute values of this relationship

NAME - name of the attribute (eg. firstname, lastname, email, ...)

DESCRIPTION

MIN_TIMES - defines how many values must be assigned to this at minimum (used for list modeling)

MAX_TIMES - defines how many values can be assigned to this at maximum (used for list modeling)

REQUIRED - a value for this attribute must be provided

VISIBILITY - defines the visibility of this attribute (public, protected, private - read more down below)

ATTRIBUTE_TYPE - defines the attribute type (eg. INTEGER, DECIMAL, STRING, ...)

The VISIBILITY of an attribute defines the scope within the attribute is visible to any accessor. If the attribute
is marked to be PRIVATE only the class or instance is allowed to read and write values from / to it. If the attribute is
marked to be PROTECTED the class or instance and all ancestors and its instances of the defining class are allowed
to read and write values from / to it. If the attribute is marked to be PUBLIC all classes and instances are allowed to
read and write values from / to it.

Although there are no limitations concerning the depth of a class hierarchy and the number of attributes within it, the user
must be aware that each new level has an impact on the overall performance of the current hierarchy.

After having defined the classes the application allows to create instances (objects) from these blueprints. Therefore the application reads the class definition (including all ancestors) and provides the user with a dialog that requires him to provide values for all attributes visible to him.

Approval engine

The job of the approval engine is to analyze incoming object orders using a XPath like expression language and forward them to a suitable set of approvers (might be a single one as well). If a required number of users have approved the order it will be either forwarded for final processing (like creating user accounts or ordering printers) or - if required - forwarded to another set of approvers (two men rule). This depends on approval information provided for the underlying class.

Each class can have one or a whole set of approval information where each element defines how entities must be handled that apply to the given path expressions:

OBJECT_CLASS - defines the class that this element provides approval information for

AUDIT_LEVEL - defines the audit level (1..n, two men rule)

DISABLED - the element will not be used by the approval engine

ORDER_CREATE_ALLOWED - if an object applies to the given path expressions, it might be created

ORDER_UPDATE_ALLOWED - if an object applies to the given path expressions, it might be updated

ORDER_DELETE_ALLOWED - if an object applies to the given path expressions, it might be deleted

PATH_EXPRESSIONS - set of strings holding path expressions. if any object positively evaluates against all of these expressions, the options mentioned above will be applied

The approval engine reads the type of an incoming object order and fetches all approval information entities for that type. All path expressions of each entity are evaluated against the object. If any of them fits, the rules defined by the associated approval information entity will be used by the engine on how to further process the object order (eg. which audit level it requires, if an object might be
created at all).

Now the engine finally needs to identify all possible approvers for the ordered object. Therefore a quite similar information entity is used. If differs from the one above only by adding the following attribute

PRIORITY_LEVEL

The PRIORITY_LEVEL is used by the approval engine in case the current set of approvers did not respond within a given timespan. Now the engine needs to forward the order element to a second/third/fourth ... round of approvers where the priority level identifies the specific round when an approver enters the ring.

Before the engine forwards an order to an approver it uses the path expression set to evaluate if the ordered object can be handled by a specific approver. If the path expressions are all valid, the engine checks if the operation (create, update, delete) might be carried out the by approver at all.

Conclusion

Although I just provided you with only a small view, I guess you got a good hint on how flexible the application's data structure is. In the upcoming articles I will talk a bit about the license model of mshop and provide you with some screenshots and more information about key features.

mShop - an introduction

2010-04-21T00:16:00.000+02:00

Today I would like to start a little series of articles about a personal software project called mShop. The mShop application is a response to a discussion I had with some friends a while ago about the handling of internal orders for office supplies and other items you need to carry out your daily work, eg. printer paper, pencils, desktop computers, user accounts or permissions. The key question was if there are any professional tools to comply with the following requirements:

define products having arbirary attributes during runtime

flexible delegation of responsibilites concerning the approval of product orders

automatic delegation of approved order items into sub-systems for further processing, eg. unix server for user account creation.

being cheap within boundaries

We came to the conclusion that there are indeed sophisticated tools like ActiveEntry or one might use an existing open source shopping platform and modify it according to his needs. BUT, the solutions are either expensive, limited in their feature set or require the owner to use their inflexible data structures.

That finally let to my decision to specify and implement an application that is compatible with the features mentioned above. According to my nick mnxfst I took the first char (m) of it and added the postfix shop.

To keep the articles short, I split them up into a series where each entry concentrates on a different key feature of mShop. The next article will discuss the definition of objects users might order via the web shop.

FetchType.EAGER - Cannot simultaneously fetch multiple bags

2010-03-21T12:59:00.004+01:00

I just came across a quite interesting problem that might give you a hint on how hibernate internally works. Assume you have the following object association:

A references B

A has a one-to-many relationship with C and the fetch type is set to FetchType.EAGER

B has a one-to-many relationship with D and the fetch type is set to FetchType.EAGER

If you try to initialize hibernate using such a layout, you will receive an error message saying something like cannot simultaneously fetch multiple bags.

Since my mappings were okay until I added a test case for B and the relationships of B were correct on first sight, I started to search for a possible reason. I came across different solutions, among them I found this one from Eyal Lupu. It did not directly solve my problem, but let me analyze the code from a different point of view.

Eyal writes, that it is not allowed to have two mapped lists in one entity being marked with FetchType.EAGER because the sql statements generated would lead to an incorrect loading of the desired entity. If you look at my example above, there is just one list per entity to be loaded eagerly, so why does it fail? The solution to that problem is the first statement of my example: A references B.

If you refer from one to another entity without further fetch type definition, hibernate will always apply FetchType.EAGER. That again leads to a join operation between the relations that contain A and B. Since the relationships between A - C and B - D are also marked to be loaded eagerly, they will be incorporated into the sql statement creation as well. Guess what operation will be used to compute the entities of the relationship: JOIN. And that leads us back to Eyals posting.

Eyal suggests to add an @IndexColumn annotation which replaces the bag semantics with list semantics that gives hibernate a hint on how to handle elements of that type. Another solution - and that's the one I chose - is to mark the connection between A and B as begin fetched lazy. In case you need the relationship between A and B being resolved on entity loading, a third solution would be to mark one or both of the one-to-many relationships as being fetched lazy.

Next to the FetchType.EAGER problem it is a good idea to have some of the relationships mentioned in the example above marked as being loaded lazy. Loading all associated objects eagerly and having a relationship that for example represent a chain of ancestors would leave you with a large set of objects loaded although you need just only one.

Object change tracking

2010-03-08T23:30:00.003+01:00

Assume you have the task to write an audit proof software that could be easily resetted into a previous, fully
operable state for all objects managed by the application. I am going to describe the approach how I solved the
issue for my assignment.

The reason for resetting a software system into a previous state is for example the ability to trace back
changes made at a specific time by a know or unknown user. Usually features like this are implemented through a
logging component having a more or less high resolution. Unfortunately the information captured only give a very
limited view on the context the changes were made in. Writing all required information into a single log entry
would be a quick but brute force solution and would let appear the log to be unreadable to auditors.

A second aspect - and that's the driving force beside the traceability of changes in my project - is the
possibility to have an automatic replay of all changes made to objects between two defined timestamps and the
provisioning of these modifications into attached sub-systems. These tasks cannot be achieved through a simple
logging mechanism since next to the data directly involded into certain actions, transitively affected information
within the context of these objects are required as well. Therefore a more complex and more complete solution
must be found which still is managable on all system levels - from abstract ui level to low database level.

A very common approach for recording changes within datasets is to save delta information representing the
transition between two states instead of creating a copy of the original state adding the changes made by the
process. The latter would lead in my case where I comprehend the whole object context as dataset to a redundant
enlargement of the whole database.

To avoid redundant information and an explosion of managed data objects, I decided to follow the idea of saving
only delta information covering the named dataset.

Within in my project, I do have to manage a lot of objects which are linked among each other and where changing a
linked objects attribute value could lead automatically to a semantic change of the originating object. Since the
changed object could be linked by n other objects, a complete and stable approach in saving the state
transition would be the storage of the changed object as well as all linking objects. This would not be as many
data as writing a whole copy of the objects context but it produces unecessary redundant information.

I decided to follow a much easier and quite simple way to solve this problem. Whenever an object changes, itself
and its ancestors can be identified for any time through the unique object id and a version stamp. All
links between objects are designed such that they reference the unique object id as well as the version stamp.

If someone changes an object, a new version is created whereas all existing links point to the version controlled
ancestor. Other objects that will be linked with the changed one in the future only see the most current version.
This leads to an overall consistent state.

But this concept is too basic to intercept all requirements. Sometimes changes to object attribute values are of
such a minor state that they would have no influence on the link semantics at all. Therefore it must be possible
to mark changes in such way that no version is created but the most current one is modified.

There is indeed the other hand extreme as well. Sometimes changes made to objects have such an impact that they
must be expanded to all linked objects too. In this case all links to former versions are upgraded to the most
current one.

Portlet Development With Spring 3.0

2010-01-10T22:48:00.007+01:00

Portlet Development With Spring 3.0

Some weeks ago I started planning a dedicated online community backed by a Liferay portal instance. Up to now I spent most of my time defining use case scenarios, evaluating software tools and convincing people from my idea. Lately I began to write smaller portlets that provide basic features which are not included in Liferay and by the way give me a deeper insight into portlet development using Liferay.

I will write more about that platform in one of the upcoming posts but for now I would like to report about my odyssey collecting information on how to develop JSR 286 portlets supported by the Spring 3.0 framework in a Liferay environment.

If you want to develop portlet for any version of the Liferay portlet, you might use the ext environment provided by the Liferay team. Although I appreciate the help to develop applications for their portal, I definately don't want to learn how to use a proprietary development environment but use my knowledge about standard portlet development and get onto the road quickly.

I searched a while until I came across some expedient documentation about how to integrate Spring 3 and standard portlets (JSR 168 and 286). The Spring framework provides you with a dispatcher portlet that maps incoming portlet requests to registered handlers.

After having assembled all required information, I started developing my first Liferay portlet. The following steps are the ones I carried out (abbreviated):

The first step creates a directory layout as follows:


/myPortlet
/myPortlet/src/
/myPortlet/src/main
/myPortlet/src/main/java
/myPortlet/src/main/java/sourceCodeGoesHere
/myPortlet/src/main/webapp/
/myPortlet/src/main/webapp/WEB-INF/
/myPortlet/src/main/webapp/WEB-INF/classes/

The next step is to add configuration files required by Liferay:


/myPortlet/src/main/webapp/WEB-INF/liferay-display.xml
/myPortlet/src/main/webapp/WEB-INF/liferay-portlet.xml
/myPortlet/src/main/webapp/WEB-INF/portlet.xml
/myPortlet/src/main/webapp/WEB-INF/web.xml

The liferay-display.xml configuration file defines the category the user can find the tool in when adding a new applicaton to a portal page (see Google for more information).

If you want to control the access to the portlet, you need to modify liferay-portlet.xml which holds the names of the role that are allowed to use the portlet (see Google for more information).

The file portlet.xml contains the core definition of you portlet: display name, class, init parameters and alike. Normally you would provide the name of your custom portlet class but since we are using Spring, we must tell the portlet container to forward all incoming portlet requests to the Spring dispatcher portlet. Additionally we need to give the path of the Spring context configuration file.:
<portlet-app> . . <portlet-name>mySamplePortlet</portlet-name> <display-name>My Sample Portlet</display-name> <portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class> <init-param> <name>contextConfigLocation</name> <value>/WEB-INF/classes/my-sample-portlet-context.xml</value> </init-param> . . </portlet-app>

At last we have the web.xml file. Internally the Spring framework handles the whole custom portlet as web application with the dispatcher portlet as entry gate. Thus the web.xml configures the custom portal application like in any other Spring application: it needs a path to the Spring context definition file, names a set of listeners and defines how to handle incoming requests (-> ViewRendererServlet).
<web-app ...> . . <context-param> <param-name>webAppRootKey</param-name> <param-value>mySamplePortletportlet</param-value> </context-param> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/classes/my-sample-portlet-context.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.util.WebAppRootListener</listener-class> </listener> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>ViewRendererServlet</servlet-name> <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>ViewRendererServlet</servlet-name> <url-pattern>/WEB-INF/servlet/view</url-pattern> </servlet-mapping> . . </web-app>

Now I need to implement a controller for handling incoming requests. Since I am mapping incoming requests to a common Spring MVC application, the implementation of a request controller takes the same steps as for a standalone web application. See Google for extended information on how to implement Spring MVC controllers, define request, action or render mappings and how to identify incoming request parameters.

I omit the source code and continue with the definition of the Spring context. As defined in the web.xml and the portlet.xml I create a new file in /WEB-INF/classes/ named my-sample-portlet-context.xml. In order to the get application running the following beans must be defined at minimum:


 <bean id="mySamplePortletViewController" class="com.me.MySamplePortletViewController">
   <property name="debugMode" value="true"/>
 </bean>   

 <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
   <property name="cache" value="false" />
   <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
   <property name="prefix" value="/" />
   <property name="suffix" value=".jsp" />
 </bean>

 <bean class="org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping">
   <property name="interceptors">
    <bean class="org.springframework.web.portlet.handler.ParameterMappingInterceptor"/>
   </property>
 </bean>

The first bean names the controller which should receive incoming requests (as defined by the RequestMapping annotations in the source code). The second bean defines the type of view used for displaying contents to the user. In this case I use JSP backed by JSTL. The last bean is the one that handles the mappings defined in the source code of the controller implementation. The provided interceptor implementation makes sure that the incoming request parameters are mapped correctly to method parameters.

Finally you need to create and implement the file (JSP) referenced in the controller source code as destination used for displaying information to the user. That's all. ... well not everything ... there are some pitfalls I stumpled upon that I would like to write about so that you are not going to make the same mistakes as I did.

RequestMappings
The JSR 168 standard only knew about request mappings, whereas JSR 286 portlets differentiate incoming requests by the phase they originate from and which purpose they serve:

Action Request (Annotation: ActionMapping)

Render Request (Annotation: RenderMapping)

Even Request (Annotation: EventMapping)

Resource Request (Annotation: ResourceMapping)

If you want to learn about these types, please check out Google for further information. I urgently advise you to use these specialised annotations although Spring lets you use the generalized RequestMapping annotation. First of all it helps to make the source code more readable, second: you know which method handles which request type, confusions excluded!

RenderMapping requires String result
As mentioned above, after processing an incoming request, the portlet controller sends the response to a defined view page. The name of that page is provided by the result of the method that handles render requests -> the method must return a string.
If it returns 'view', the user will be redirected to 'view.jsp'.

Unit testing
If you want to test your portlet controller, check out the test cases for the Spring framework itself. Since the usage of init methods is quite common, you should be aware that the init method of your controller is executed before the setUp method within a JUnit test case. So, if you plan to access data in your init method which is created by the setUp method, you need to explicitly call the init method in your test method.

Thoughts on Google Wave

2009-12-17T22:32:00.001+01:00

Lately I received an invitation to Google Wave from a colleague at the otto group (btw, thanks for that, David).

First I thought, that Wave is another way of spending my precious time. Some people say, that Google just tries to revolutionize the communication tool market with its Google Wave application and are curios if that will work given the set of existing communication tools with their broad feature set. Beside that some point out that the feature of adding arbitrary content at any location within a wave could discourage non-digital natives from using the new technology.

I fully agree that Google tries again to revolutionize a market, but I disagree with the implicated estimation that Google just adds another communication tool. Although Wave is still in beta mode, it is already visible what the driving force behind the scene is. Google does not provide us with another isolated publishing pipe like Twitter or alike but enhances our way of information exchange by combining different communication channels into an integrated application.

From my point of view, one of the main problems with today's communication tools is the fact that some of them are very famous but none of them really maps the real life way of conversation into the digital world. That again leaves us with sometimes fragmented conversations that are unnecessarily protracted because the exchanged textual informations (for the case of an email) do not fully explain the intentions of the participants. In real life we tend to support such situations with additional material from different sources, eg. maps or photos, to clarify our statements.

Google actually tries to solve what I expressed in my last statement: support a conversation with information from a variety of sources. Make no mistake about the hype Google created around Wave, the application is still under development and has more the feeling of a very active research project than an enterprise enabled communication tool. But if you strip down the initial character of its current state (by 17/12/2009) you must realize that Google heralds a new era of compelling messaging experience as for example Mozilla also tries do achieve with its Raindrop project.

Finally neither the Google nor the Mozilla approach will help us today to avoid the face-off with situations like Frank Schirrmacher wrote about: he complained that his head cannot follow the constant flow of information anymore (see www.spiegel.de, german only). But on the other hand they help us to steer into the right direction. A very tiny but important step is the traceability of a Waves conversation history which does not only help the non-digital natives to find out when a certain piece of information was inserted into a conversation and by whom.

Hourglass display with Richfaces

2009-12-01T14:17:00.005+01:00

Hourglass display with Richfaces

Yesterday we started with a preliminary application test to be prepared for the final integration test next month.
Since the web based application works on large datasets which could sometimes lead to extended response times at
frontend level, one of the first things the users asked for, were a hourglass or something alike to show that the
server is still processing the request.

Since the application is based on Richfaces I searched for any feature that could help me and discovered the status tag.

The first thing I wanted to try out, was to display a message simply informing the user that the current request is still in processing mode. In order to do so, only two things needs to be done:

Define the message display behaviour using the status tag

Bind the status handler to a control that sends an ajax request to the backend


  <a4j:status id="testStatus" startText="Request processing started" stopText="Request processing ended"/>
  <a4j:commandButton action=".." value=".." status="testStatus"/>

The next time the user clicks on the command button a message will appear and inform him about the processing state.

Well, that kind of behaviour gives your users a slight hint on what the system is currently doing, but hey, an overlay graphic displaying a hourglass or alike is much cooler, isn't it. Therefore I continued to search for an appropriate solution to that
problem and finally found one written by Markus Kühle (in german only). Compared to my little example above, the main concept does not change. A status handler is defined as well as the binding with the command button. In order to create an overlay message, we need to work with cascade style sheets:


* html body { margin: 0; overflow-y: hidden; padding: 0; }

#globalStatusDiv {
  position: relative;
  left: 50%;
  top: 200px;
  width: 100px;

  text-align: center;
  margin-left: -50px;
  height: 25px;
  line-height: 25px;
  background-color: #FFF;
  padding: 2px 15px 2px 10px;
  color: #000;
  font-family: Verdana,Arial,Helvetica,sans-serif;
  font-size: 14px;
  font-weight: bold;
  z-index: 10000;
}

#globalStatusDiv img {
  vertical-align: middle;
}

Next, we must define a div which contains the information to be displayed and bind it to a status tag:


<link href="/css/status.css" rel="stylesheet" />
<div id="globalStatusDiv" style="display:none;">
  <img src="/images/working.gif"/> %<h:outputText value="#{generalMsg.general_loading_message}"/>
</div> 
<a4j:status id="globalWaitStatus" forceId="true" layout="none"
            onstart="jQuery('#globalStatusDiv').fadeIn('fast')"
            onstop="jQuery('#globalStatusDiv').fadeOut('slow')" />

The binding with a command button does not differ from the simple example above:


<a4j:commandButton action=".." value=".." status="globalWaitStatus"/>

How to convince people of good ideas

2009-10-07T11:59:00.001+02:00

Although I originally planned / promised to write about caching strategies and method interception in spring
applications, I decided to insert a different topic that concerns me since I gave a presentation the other day.
The main goal of that event was to show the current implementation state to the upcoming users.

The initiator of that project defined the platform in a very broad manner and with a scope that overlapped
more than one company. In doing so an integrated management process could be achieved for handling user/object
associations which would unify existing concepts that are alike for all expected participators - that implicates
that all of them currently hold and maintain individual applications for handling their own isolated process.
It's needless to mention that the unification of theses processes would lead to an economization even for
future applications. This affects the support for such a process as well as the application administration and maintenance.

Up to here the idea sounds very promising and reasonable. That's maybe why we were commissioned to implement
that piece of software. Unfortunately the project was altered within the scope of the number of participants and
thus in its importance. By reducing the scope to currently one / two partners, the whole idea was definitely
crippled. Although it's crucial to mention that the implication of such a project is the requirement for an even
bigger project that has the goal of unifying the required meta data and management concepts. On the other hand
even that project would lead to a unified concept on a more abstract level.

The question I ask myself now, is how to convince the people in charge of broadening the scope to the one formerly
defined and turn the project into an overall success? I appreciate all comments on that issue.

Why more software developers should write blogs

2009-09-15T21:45:00.004+02:00

It's been a while since I wrote my last blog post and with a view to Dustin Marx comment on software developers that should write blogs, I feel to be caught red-handed.

To improve myself, I noted two topics, I would like to talk about in the upcoming posts:

caching strategies in web applications

method interception in spring

Apple sauce

2009-09-06T12:37:00.008+02:00

Today I got up and looked out of my living room window and saw that the nightly wind has torn off a large amount of apples from the tree in our garden. Since I really like to eat apple sauce as side dish, I decided to pick up some of the fruits and cook them. I found a rather simple recipe although it does not avoid the work to peel the apples:

* peel the apples and remove all decayed pieces
* cut the remaining parts into small pieces
* put 250g of apples and 6 table spoon of water into a small box that can be placed in a microwave
* heat the box for 6min in the microwave (800W)
* mash the cooked apples and mix it with sugar as you like it

Acutally I don't know how long it can be stored in the fridge.

Spring Security - Basics

2009-08-31T13:15:00.033+02:00

During the last days I had the assignment to secure a spring based application I currently work on. Although I had no experience integration spring security into an application, I decided to use this standard technology rather than writing my own security layer.

The task to accomplish was well-defined:

provide a form-based login mechanism

authenticate the user against a local database

role/group information are not required since they arise from the data that will be processed by the application
support the user with complete and meaningful error messages

Unfortunately the documentation which is available for spring security (M3) is not very exhaustive and thus not helpful in order to reach the designated goal quickly. Thus I dug myself through various sources including forum posts, javadocs, documentation of earlier spring security versions and sourcecode. Finally I had a set of information which helped me to assemble a login module for my application.

Basic configuration

<b:beans xmlns:security="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd>

<security:http entry-point-ref="customAuthenticationEntryPoint"
session-fixation-protection="newSession" access-denied-page="/index.jsp">
<security:logout logout-success-url="/index.jsp" invalidate-session="true"/>
<security:anonymous username="guest" granted-authority="ROLE_ANONYMOUS"/>
<security:intercept-url pattern="/dialogs/**" access="ROLE_USER"/>
<security:intercept-url pattern="/index.jsp" access="ROLE_ANONYMOUS"/>
</security:http>

<authentication-manager alias="authenticationManager"/>

<b:bean id="customAuthenticationManager" class="CustomAuthenticationManager">
<b:property name="userService" ref="userService"/>
<b:property name="passwordEncryptionAlgorithm" value="SHA"/>
<b:property name="baseRoleName" value="ROLE_USER"/>
</b:bean>

<b:bean id="customizedUrlAuthenticationFailureHandler" class="CustomAuthenticationFailureHandler">
<b:property name="defaultFailureUrl" value="/index.jsp"/>
</b:bean>

<b:bean id="customizedFormLoginFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationProcessingFilter" >
<security:custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/>
<b:property name="authenticationManager" ref="customAuthenticationManager"/>
<b:property name="allowSessionCreation" value="true"/>
<b:property name="authenticationFailureHandler" ref="customizedUrlAuthenticationFailureHandler"/>
</b:bean>

<b:bean id="customAuthenticationEntryPoint" class="CustomAuthenticationEntryPoint">
<b:property name="loginFormUrl" value="/index.jsp"/>
</b:bean>

</b:beans>

security:http

The first block configures the security layer as such. It defines the entry point into the layer (customAuthenticationEntryPoint) where all requests will be redirected to, the urls to secure (intercept-url) and the logout behavior (logout-success-url).

customAuthenticationManager

The customAuthenticationManager bean implements the core authentication behavior. Incoming requests that belong to an user session which has not passed the security layer before are handled by this bean. It overrides the authenticate method and performs the necessary principal and credentials checks.

customizedUrlAuthenticationFailureHandler

The customizedUrlAuthenticationFailureHandler defines the steps to carry out in case the authentication fails. In this case I created a new one next to the standard implementation since I had the requirement to implement a special error handling.

customizedFormLoginFilter

The customizedFormLoginFilter defines that the application uses the basic username / password scheme to authenticate new users. Spring security also provides implementations for open id authentication or CAS.

customAuthenticationEntryPoint

The customAuthenticationEntryPoint defines the class that provides the implementation of the authentication entry point of the security layer. All incoming requests will be directed into this class. I use the commence method to remove all previous error messages.

As you can see, the configuration (and implementation) of a custom spring security login filter is straight forward. Since I did not want to overflow the blog with source code, I omitted it. If you are interested in it, feel free to contact me.

FileUpload with Richfaces

2009-08-21T19:18:00.020+02:00

The other day I had an assignment to write a CSV upload and download interface for a JSF (Richfaces) based web application. On first sight, that isn't a really tricky task since it was realised many times before by a lot of people - including me. Therefore I was quite confident to implement that feature quite quickly ... until it came to the point where I tried out what I implemented. Unfortunately, the file was not uploaded although my code wrote the correct filename to the log output. This is my sourcecode:


public void uploadListener(final UploadEvent uploadEvent) {
  UploadItem uploadItem = uploadEvent.getUploadItem();
  String fileName = uploadItem.getFileName();
  String csvFile = new String(uploadItem.getData());
  ...
}

The method signature follows the requirements set by richfaces in order for a method to receive incoming upload events. Usually the upload item variable should contain all required information, especially the required file data.

The reason why the upload item is not filled as expected, is the AJAX filter option createTempFile which is set to true by default. Under these circumstances the uploaded file data will not be made available to the upload item variable, but is written into a temporary file on disk. To change this behavior, its necessary to switch the config option of org.ajax4jsf.Filter to true in the web.xml.

Initial Commit

2009-08-21T14:11:00.016+02:00

Hello everybody and welcome to my new blog. I guess most people starting a blog have thoroughly planned the topics they want to write about. Actually I did the same, but writing an inital post to introduce the blog and its author is much harder than expected. I could write a long essay about me, my work and how I made the decision to start this blog - probably most people would be bored beyond belief. Therefore I omit that and give you a quick summary about me and the topics you can expect from the upcoming posts.

Who am I?
My name is Christian Kreutzfeldt and I work as a software engineer in Hamburg / Germany. Mainly I deal with a lot of topics that are associated with the development of enterprise software written in JAVA. Actually I work on a project that deals with the definition and implementation of a role and permission management.

What can you expect?
As you can read in the nice textare that covers my face in the page header, I stumble upon a lot of interesting topics during my day-by-day work. I plan to use this blog as a kind of reference book for myself as well as an information assembly for others. Most topics that I will cover will be associated with J2EE in the one or another way.