Scarlet 1.0 RC2 is out!

Short news just to let you know that the Scarlet second release candidate is officially out!

This is your last chance for submitting bugs, suggestions and feedback about Scarlet, prior to its final release, scheduled for the end of this month.

So don't hesitate to contribute to the unique Open Source clustering solution for your preferred enterprise issue tracking software!

Enjoy it!

Scarlet first release candidate is out!

Exciting news about Scarlet are coming!

The new Scarlet 1.0 Release Candidate 1 is officially out, with new features, several enhancements and fixes, and a brand new web site!
Can't wait for it?
Take a look at: http://scarlet.sf.net!

Talking about the technical side of this new release, the most important changes concern the upgrade to Atlassian Jira 3.12, improved APIs for plugin development and a performance boost of about 20%.

However, what most excites me is the new Scarlet infrastructure, based on Sourceforge:

• The web site, with growing documentation.


• Forums and mailing lists, for easily getting help, sharing feedback and discussions, and staying in touch.


• A public Jira space (thanks to Atlassian), for actively contributing to the Scarlet development by tracking bugs and feature requests.


• A widely accessible download system.

This is to lay the foundation for a true open source community behind Scarlet, which is currently our primary goal ... together with providing you the best Jira clustering solution around, obviously!

Now, it's your turn!

See you at Javapolis!

I'm going to leave Rome and catch my flight for Antwerp.
Actual destination : Javapolis!

I will hold a BOF, so don't miss it.

See you there!

Owner Based Locking explained

If you attended my presentation at the Rome JavaDay about my real world experience in clustering Atlassian Jira, or if you took a look at my slides, you may already know that one of the challenges was the rewriting of the Jira caching system.
The hardest part of this challenge was to define the cache locking strategy.
That was because of two requirements, due to the Jira code and the way it has been clustered:

• The need to associate more caches under the same lock.


• The need to execute arbitrary code blocks atomically: that is, again, under the same lock.

So here it comes my idea of the owner based locking.
It's very simple and I'll explain it in a moment: others may find it useful, or elaborate on that for solving their own locking problems, or just provide useful suggestions.

Let's start with the concept of cache group. The cache group is the entry point for your caching system, where you create caches, put things and get back them and alike.

First step : when you create a cache into the group, assign it to an owner.

The owner is a string, and nothing more. It just serves two purposes: it's the name which associates different caches, establishing some kind of caches sub-group, and their lock.

Here it comes the second step : use the owner as a lock for different caches sub-groups.

This is a lock striping technique.
Lock striping techniques prescribe you to distribute your data in several "stripes" and split your big, fat, lock in several locks, assigning each one to a different stripe : this is done for enhancing thread concurrency, given that different threads will be able to concurrently access different parts (stripes) of your data because guarded by different locks.
In our caching system, the stripes are the different caches sub-groups, and the locks are the owners.
A code snippet will help clarifying.
Here is how a value is retrieved from a cache into the cache group:

    public Object get(String cacheName, Object key) {
        CacheHolder holder = (CacheHolder) this.group.get(cacheName);
        String owner = (String) holder.getOwner();
        synchronized (owner) {
            Map cache = holder.getCache();
            return cache.get(key);
        }
    }

As you can see, the synchronized variable is the owner string: by doing so, caches with the same owner will be protected by the same lock, while caches with different owners will be accessed concurrently, but without compromising the whole thread safety.

Finally : use callbacks for atomically executing code blocks.

This is best explained by first showing the callback interface:

    public interface AtomicContext {
     
        public Object execute();
    }

And how it's used into the cache group:

    public Object executeAtomically(AtomicContext context, String owner) {
        synchronized (owner) {
            return context.execute();
        }
    }

As you can see, the execute() method is executed atomically under the given owner lock.
However, here I have to raise a warning flag: if the implementation of the execute() method uses caches belonging to other owners, it may cause deadlocks; so take care and use only caches whose owner is the same as the one provided to the executeAtomically() method!

That's the owner based locking.
You can take the full source code of the cache group used for clustering Atlassian Jira from the Scarlet Jira extension distribution.

Any feedback will be highly appreciated.

Cheers!

News about Scarlet

One month has passed since my last post, due to the fact that I've been very busy working at the hottest (well, maybe I'm a bit biased here...) Jira extension around : Scarlet.
Here are some news about it:

• Me and my colleague and friend Ugo talked about our experience in clustering Jira with Terracotta at the Rome JavaDay: people really appreciated it, and if you weren't there (or if you liked us so much that you want to read them again) you can take a look at the slides (in English language) here.


• We've just released the Scarlet Beta 2 version! Take a look at the full announcement here.

As always, every kind of contribution will be welcome.
See you!

Scarlet is out!

As I said some weeks ago, in the past two months I've been deeply involved in clustering one of the most important Open Source enterprise applications around.

Now, it is time to unveil the amazing work done here in Sourcesense, because the first public beta release of Scarlet is officially out!

Scarlet is a free, open source, clustering extension to Atlassian Jira, providing scalability and high availability to the most famous and widespread issue tracking software.
It is based on Terracotta DSO, so it's a completely transparent / easy-to-setup clustering solution: no new things to learn, no complex configurations to apply, no expensive hardware to buy ... just the same old Jira!

It has been a very challenging work with a lot of interesting technical issues: you'll surely read some articles about them in the (very) near future.

In the meantime, download and learn more about Scarlet here.
Play with it.
We need any kind of feedback : suggestions, feature requests, bug reports and alike.
Do not hesitate.
We need you.

Introducing the Scala Language

It is both a pure Object Oriented and fully featured Functional language.
It is both a scripting language and a compiled one.
It is a stable, solid, well designed language.
It has been very well received by a lot of people and has thousands of downloads per month.
It runs on the Java Virtual Machine and fully interoperates with the Java environment.
It has been called the "next next Java".
It is the Scala Language.

I've recently started to learn and play with it and I have to say I'm really enjoying its features.
For those with very little Functional Programming background (as I am) it may have a steep learning curve and its language features may seem too vast, but don't let them discourage you!

First start with this excellent tutorial.

Then I suggest you to start learning the following features:

• All about classes, singleton objects, abstract types and traits.
• Mixins.
• Type inference.
• Infix and postfix operators.
• XML processing.

These are in my opinion the most important and interesting object oriented capabilities of the Scala language.

Then go with its functional side:

• All about functions.
• For comprehension.
• Case classes (still to learn).
• Pattern matching (still to learn).
• Views (still to learn).
• ... (still to learn).

As you can see, I have still a lot of things to learn, but I think that just its object oriented and most basic functional features make Scala a great language and a great learning/programming experience!

What about some practical use cases?

Right now I see it very well suited for:

• Creating Domain Specific Languages (DSL) to integrate in Java applications.
• Producing XML documents starting from data expressed in objects or some kind of DSL.

Stay tuned.
More info and ideas about my experiences with the Scala language will come soon.

The Fail Fast Rule

Every time you're writing a piece of code and you have to deal with unknown corner cases ...
Every time you're implementing some kind of logic and you don't know what to do when things go bad ...
Every time you think: this can never happen, I don't have to check for it ...
Every time you don't know what to do or what would happen ...
Please ...

Fail fast.

This is the Fail Fast Rule, as I call it, a term borrowed from the Java Collections iterators behavior:

Every time your code might fail, and you don't know what to do, just make it fail abruptly.

That is: do not ignore it, do not (just) log it, but let your code throw an exception.

An example was how we computed a shopping cart total in one of my previous posts:

public class ShoppingCart {
    
    private static final int MAX_TOTAL = 10000;
    
    private List orders = new ArrayList();
    
    public void addOrder(Order o) {
        this.orders.add(o);
    }
    
    public double computeTotal() {
        double total = 0;
        Iterator it = this.orders.iterator();
        while (it.hasNext()) {
            Order current = (Order) it.next();
            total += current.computeSubTotal();
            if (total > MAX_TOTAL) {
                throw new SomeException();
            }
        }
        return total;
    }
}

As soon as the total gets too high, an exception is thrown. Probably this will change later, because we may want to handle it more gracefully, but in the meantime: make it fail.

Why?

Because if an exception will pop up in front of you, you'll have found a bug, a corner case, something that you have not still properly implemented or that you have not thought of.

So remember: make it good, or fail fast.

JavaMail and GMail : it's all about configuration

Yesterday I spent a couple of hours trying to send emails with JavaMail APIs via my GMail account.

It wasn't easy: the standard JavaMail configuration didn't work, while Google gave me a lot of wrong and/or outdated information.
Moreover, JavaMail FAQs provide a sample about sending emails via GMail, but it has some problems too.

So I think these bits of information will be helpful to someone trying to accomplish the same task ...

The problem is that GMail uses TLS and the STARTTLS command.
The solution applies to JavaMail 1.4 and JDK 1.4 or higher and is just a matter of configuration.

First, and obviously, enable POP support for your GMail account.

Then, put the following configuration in your properties file:

mail.transport.protocol=smtp

mail.smtp.host=smtp.gmail.com

mail.smtp.starttls.enable=true

mail.smtp.auth=true

mail.user=<your_username>

mail.password=<your_password>

The key point is the part in bold: enabling the STARTTLS command.
That's the tricky part.
Once created the properties file above, just configure your JavaMail Session object and send your mail message as you'd always do:

Properties props = ...; // <-- Your properties above

Authenticator authenticator = new YourAuthenticator(...);

Session session = Session.getInstance(props, authenticator);

Transport t = session.getTransport();

t.send(yourMail);

That's all.
Feel free to comment on for any question.
Enjoy it!

Avoid your getters and setters, Part 2

More than one year ago we've talked about how to avoid getters and setters by using the most fundamental object oriented programming principle: programming to an interface.

Well, it was just the beginning ...

I know we're a bit late, but let's go now with the second part of my How to avoid getters and setters series ... I hope you'll enjoy it!

Avoid your getters and setters : The Expert, the Aggregate and the Value Object.

Many people use getters and setters so extensively because don't really get the importance of correctly assigning object responsibilities and behaviors.

So, in this second part we'll mix together GRASP and Domain Driven Design patterns, in particular:

• The Information Expert pattern.
• The Aggregate Root pattern.
• The Value Object pattern.
  

We'll see how wrongly managing responsibilities and behaviors, while abusing getters and setters, can lead to a corrupted business domain, and how the patterns above will help you to correctly address these kind of problems.

The business domain.

Let's start our discussion by showing a simple business domain.
We're implementing yet another ugly e-commerce system, so we have a shopping cart holding a number of orders, each referring to a given product.
Without going further on, let's restrict our domain model to three simple entities: ShoppingCart, Order and Product.









A ShoppingCart can hold one or more Orders, and an Order refers just to a single Product.
Moreover, we have some simple business rules regarding these entities:

1. The ShoppingCart total is the sum of all Order sub-totals.
2. Each Order sub-total is the Product price times the ordered Product quantity.
   
3. The ShoppingCart total cannot exceed the value of EUR 10000.

Pay particular attention to the latest point: it is an invariant, a rule that must be always kept valid.

That's all.
Very simple, isn't it?

Let's implement it : the wrong way.

The entities and rules above can be straightforwardly implemented as follows:

public class Product {

 private String name;
 
 // ...
 
 private double price;

 // ...
 
 public double getPrice() {
  return this.price;
 }
 
 public void setPrice(double price) {
  this.price = price;
 }
}

public class Order {

 private Product product;
 private int quantity;
  
 public Product getProduct() {
  return this.product;
 } 
  
 public void setProduct(Product p) {
  this.product = p;
 }
 
 public int getQuantity() {
  return this.quantity;
 } 
  
 public void setQuantity(int q) {
  this.quantity = q;
 }
}

public class ShoppingCart {

 private List orders = new ArrayList();
  
 public void addOrder(Order o) {
  this.orders.add(o);
 }
 
 public List getOrders() {
  return this.orders;
 }
}

As you can see, all classes have the right properties and dependencies:

1. A Product has a price.
2. An Order refers a Product and has a product quantity.
3. The ShoppingCart has more orders.
4. The ShoppingCart total can be calculated by iterating all Orders and summing up each Product price times the ordered product quantity.

However, this design (and implementation) is seriously flawed:

• There's no clear assignment of responsibilities and behaviors.
  
• Hence, it is full of getters and setters.
• Hence, there's no encapsulation.
• Hence, all business logic is external.
• Hence, it is easy to corrupt domain state and violate business rules.

How?

Given our design and implementation, the following code is absolutely legal:

Product p1 = new Product();
Product p2 = new Product();

p1.setPrice(1000);
p2.setPrice(2000);

Order o1 = new Order();
Order o2 = new Order();

o1.setProduct(p1);
o1.setQuantity(5);

o2.setProduct(p2);
o2.setQuantity(5);

ShoppingCart cart = new ShoppingCart();

cart.addOrder(o1);
cart.addOrder(o2);

But hey, wait!
The ShoppingCart total is now EUR 15000!
That's because the business logic is computed outside of the object that holds the information; so let's solve this problem by introducing the Information Expert pattern.

Refactoring toward the Expert.

The Information Expert pattern is part of the General Responsibility Assignment Software Patterns (GRASP), and states the following:

Assign a responsibility to the information expert: the class that has the information necessary to fulfill the responsibility.

We have two responsibilities to relocate:

• The shopping cart total computation: here, the information expert is the ShoppingCart class.
• The order sub-total computation: here, the information expert is the Order class.

By relocating the two responsibilities we'll improve our encapsulation and make our implementation more robust, because the ShoppingCart will be able to check that the total doesn't exceed EUR 10000.

public class Order {

 private Product product;
 private int quantity;
   
 public void setProductWithQuantity(Product p, int q) {
  this.product = p;
  this.quantity = q;
 }
 
 public double computeSubTotal() {
  return this.product.getPrice() * this.quantity;
 }
}

public class ShoppingCart {

 private List orders = new ArrayList();
  
 public void addOrder(Order o) {
  this.orders.add(o);
 }
 
 public double computeTotal() {
  double total = 0;
  Iterator it = this.orders.iterator();
  while (it.hasNext()) {
   Order current = (Order) it.next();
   total += current.computeSubTotal();
                        if (total > MAX_TOTAL) {
                                throw new SomeException();
                        }
  }
  return total;
 }
}

As you can see, the ShoppingCart computeTotal() method is now able to check against the maximum total, and throw an exception if there's something wrong, avoiding domain state corruption.

However, there's still something wrong; take a look at the following code:

Product p1 = new Product();
Product p2 = new Product();

p1.setPrice(1000);
p2.setPrice(2000);

Order o1 = new Order();
Order o2 = new Order();

o1.setProductWithQuantity(p1, 2);
o2.setProductWithQuantity(p2, 4);

ShoppingCart cart = new ShoppingCart();

cart.addOrder(o1);
cart.addOrder(o2);

cart.computeTotal();

// !!!!!!!!! DANGER !!!!!!!!!!
o1.setProductWithQuantity(p1, 3);
// !!!!!!!!! DANGER !!!!!!!!!!

The problem is that we can always change the Order product and quantity, changing so the shopping cart total without preventing it to enter in an invalid state!

Where's the real problem?
How to solve it?

Refactoring toward the Aggregate and the Value Object.

The real problem is that we are interested in keeping the ShoppingCart state always correct, that is, in keeping its invariants: however in the current design and implementation we are not able to control everything happens inside the ShoppingCart, because we can directly modify its Orders without going through it!

The solution is to apply the Aggregate and Value Object patterns, part of the Domain Driven Design.

An Aggregate is a set of related objects whose invariants must always be kept consistent, and an Aggregate Root is an object that acts like the main access point into the aggregate; all access must go through the root, and objects external to the aggregate cannot keep references to objects contained into the aggregate: they can keep a reference only to the aggregate root.

A Value Object is an object that has no identity and is immutable: it is equal to another value object of the same type if its properties are equal too, and must be discarded if its properties need to change.

How to turn this theory into practice, applying it to our domain?

First, our ShoppingCart and Order are part of an aggregate.
It's easy: the "EUR 10000" invariant involves both objects, so it must be kept consistent across the two.
Moreover, Orders make sense only if related to a ShoppingCart, so no one should access an Order without first going through a ShoppingCart: this means that the ShoppingCart is the root of the aggregate.

Second, the Order is a Value Object: it doesn't make sense to create an order and change its related product and quantity during its life cycle; an order always refers to the same product with the same quantity, and if something needs to be changed, it must be discarded and a new one must be created.

Now let's refactor our previous code:

public class Order {

 private Product product;
 private int quantity;
 private double subTotal;
   
 public Order(Product p, int q) {
  this.product = p;
  this.quantity = q;
  this.subTotal = this.product.getPrice() * this.quantity;
 }
 
 public double computeSubTotal() {
  return this.subTotal;
 }
}

public class ShoppingCart {

 private List orders = new ArrayList();
  
 public void addOrder(Order o) {
  this.orders.add(o);
 }
 
 public boolean removeOrder(Order o) {
  return this.orders.remove(o);
 }
 
 public double computeTotal() {
  double total = 0;
  Iterator it = this.orders.iterator();
  while (it.hasNext()) {
   Order current = (Order) it.next();
   total += current.computeSubTotal();
  }
  return total;
 }
}

The Order class is now immutable and part of an aggregate together with the ShoppingCart.
The ShoppingCart is now the aggregate root, and every change to its Orders must go through it.

Now, you have no way of corrupting your domain.

Remember: the Expert, the Aggregate and the Value Object.
Who do you want to be?

Alive

Hi all.

I'm not going to talk about the great Pearl Jam song.
I'm going to talk about me, because (very) long time has passed since my last post, and yes ... I'm still alive.

I don't want to bother you too much, just let me jumble a few bullet points about the most important things happened to me during these months:

• I finished working at that big project for RAI, the Italian State Television, involving the design and development of its main portal. It was a very interesting experience and I think I'll write more about things I learned (because we always learn), in the future.
• I became a committer of the Taconite Ajax Framework, improving my Javascript skills and working with CSS Selectors.
  
• I've been at Spring One 2007 and it was nice, even if it didn't fulfill my high, maybe too high, expectations.
• I bought a white MacBook and I'm really happy with it.
• I've started working at (and I'm still doing) clustering a famous Open Source Enterprise product: I cannot say more right now, but I think more news will pop out soon.
• Spring Modules approached the 0.8 release and will (hopefully?) soon approach the 0.9 one.
  
• I've changed houses, and I'm really happy in the new one.
• Radiohead released their new album, after about four years of silence ... and I suddenly bought it.
  
• ... I've started blogging again ... seriously!

That's all.
Now let the thoughts flow again.
Now let the fragments burst in the air.

Join Us: Be Commons-Logging Free!

Johannes invited his readers to revise their code in order to remove all dependencies on Jakarta Commons-Logging (JCL).

Why?
It is simple: JCL gives you a lot of class loading problems, often driving you mad.
If you've never had class loading problems while deploying your Simple Servlet / Complex JEE application which makes use of JCL, if you've never struggled for making JCL use that damn Log4j configuration file, you're surely one of the luckiest person in the world, so hurry up and go buying that lottery ticket!

That's way I always use, at least when possible, raw Log4j loggers.

However, thanks to Johannes I've discovered SLF4J: I gave it a try and in less then two minutes I've migrated my current project from JCL to it!
And what's most important : it rocks!

So, again: join us and be Commons-Logging free!

Five things you don't know about me

Some weeks ago I've been tagged by Daniele , but I'm very busy to do anything other than working at a big project for RAI .
So, now, let me start the new year with five things you don't know about me:

• I used to practice martial arts: more specifically, Shorinji Kempo.
  
• I used to play guitar in a Rock band called Voodoo Economics.
• I used to write short novels, and I also won a prize.
• I have very little spatial ability and I often lose my way (literally).
• My nickname, Tourist, is related to the homonym Radiohead song: The Tourist.
  

This silly thing has to have an end ... so here it is!

Spring Modules 0.7 and XT Framework Highlights

Hi guys,

I'm pleased to announce here the new Spring Modules 0.7 release.
We have made several changes (you can find the general changelog here), so I suggest you to update to the new release.

Talking about the XT Framework, here is a short list of the most important changes:

XT Modeling Framework :

• New annotations for better controlling the DynamicBeanIntroductor behaviour.

XT Ajax Framework :

• Enhanced integration with Prototype and Scriptaculous JavaScript libraries (in particular, full support for effects and drag and drop).
• New components, in particular the JspComponent, which let you dynamically send JSP contents through Ajax.
• Support for mapping more Ajax handlers to the same web path.
• Enhanced DefaultValidationHandler, for easy Ajax validation.

Take a look at the whole XT documentation for a full taste of all XT Framework features ... any feedback will be very welcomed!

As a final, yet important, note, I'd like to thank all the Spring Modules community, and all Spring Modules developers: it's always a pleasure to work with keen guys!

Spring 2.0 and the P-Namespace

Some days ago Rod Johnson blogged about an undocumented feature of Spring 2.0: the so-called P-Namespace, which permits you to shorten the XML configuration.
This feature has been very well welcomed by the developers community, because it clearly makes the Spring XML configuration easier to manage and read, without running into the burden of writing a custom namespace handler.

I strongly suggest you to give it a try.

As a consequence, many people started asking more, and in particular many people I know asked about the possibility of applying the same kind of configuration to collection and map properties.
Too bad, this seems to be impossible, but I'm here for giving my two cents about another (documented) way of configuring collections, that is IMHO easier to read. It uses the P-Namespace and the util schema, here is a sample:

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
      xmlns:util="http://www.springframework.org/schema/util"
      xmlns:p=" http://www.springframework.org/schema/p"
      xsi:schemaLocation="
      http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util
      http://www.springframework.org/schema/util/spring-util-2.0.xsd">
 
   <util:set id="contents">
       <bean id="c1" class="org.acme.Content" p:name="c1"/>
       <bean id="c2" class="org.acme.Content" p:name="c2"/>
       <bean id="c3" class="org.acme.Content" p:name="c3"/>
   </util:set>
 
   <bean id="container" class="org.acme.Container" p:name="container" p:contentList-ref="contents"/>
 
</beans>

As you can see, you have to simply configure your collection with the util schema (that makes it reusable, too), and then inject it with the P-Namespace!

I hope you'll find it useful!

Maven2 : Evil or Not?

Guys, I have very little time to blog these days, too much work, but let me do a complaint.

Since my colleague Gianugo talked me about it, I've always been a strong supporter of Maven2.

It is true that it is a kind of black magic.
It is true that it has a (very) poor dependencies conflict resolver.
But hey, it let you manage your build process with very little configuration effort, has a good convention over configuration approach, let you centralize your dependencies, has a wide community and ... is cool (should I have mentioned this as first?).
So, since I started to use it, I have to say it helped me very much in speeding up my build management process.

But please, guys: can someone tell me why there are tests that succeed when executed by my preferred IDE, and fail when executed by Maven2?

Weeks ago I've already discovered serious problems between Maven2 and static inner classes, but now I can't really find any workaround.

Some times ago my colleague Ugo Cei started blogging about the question: Goolge: evil or not?

Now it is my time: Maven2 : evil or not?

Java Interfaces or Abstract Classes?

These days there's a very interesting discussion on the Domain-Driven Design mailing list about the use of "pure" Java interfaces (the one expressed by the interface keyword) or classic abstract classes for modeling and implementing domain objects.

I strongly suggest you to read the whole thread.

But for now, let me summarise a bit.

I'm a strong supporter of the use of interfaces in domain model.
As I already explained in one of my old posts, my main point is that pure interfaces let you clearly separate the business behaviours and contracts from implementation details. In particular, they let you clearly express what is the published interface, and what the public one: this enables you to write code that depends only on interfaces that actually express domain concepts, without worrying about implementation-only methods.
As a side note, interfaces let you easily test your system.

Those that prefer to use abstract classes argue instead that interfaces cannot fully express domain contracts, because they are just "signatures with no body", while abstract classes carry an implementation and so are able to express those missed contracts.
Moreover, they mainly see interfaces as a way of enabling multiple implementations/inheritance: if no multiple implementation is needed, there's also no need for an interface.
Finally, they think interfaces ara against evolutionary design because evolving the design by adding a method to an interface breaks all implementors.
Following their point of view, so, interfaces for domain objects are mostly just one more indirection, just one more useless source file.

I fully understand their points, but I disagree with many of them.
I obviously cannot say that the pure interfaces approach is absolutely better than the other: everything has pros and cons, but I still prefer it.
It is not because using abstract classes is wrong.
Too bad, I think there's a base misunderstanding between the two. Trying to clarify, I'd like to highlight the following points:

• It is true that you cannot fully express all you contracts using just interfaces: in fact, I suggest to use interfaces plus abstract classes, or eventually AOP aspects expressing business contracts.


• Programming by "pure" interfaces doesn't mean you have to make an interface for every class: it just means you have to make an interface for main business concepts whose interface methods will be referenced in your code.


• When you program by ("pure") interfaces and you are in the situation where you need to add a method in your interface, if that method doesn't fit into all implementors, this means that you have wrong interfaces and you need refactoring. This is because the adding of a method into an interface must be driven by its contracts, and if an implementor doesn't need that method, it may be that the implementor should not have that interface.


• Pure interfaces are not against evolutionary design, because you can introduce them inch by inch in your design and use refactoring for supporting changes.

That said, I'd like to hear your thoughts, my reader ... any opinion?

Integrating Prevayler into Spring: ease your persistence with Prevayler-Template.

System prevalence is a term coined by Klaus Wuestefeld, denoting a transparent persistence solution.

Let me give some more details for understanding what that means.

A prevalent system is a system made of business objects which obey the following rules:

• They must be serializable.


• The must be deterministic, that is, given some input to a business method, it must always return the same output.

A prevalent system is always fully kept in RAM and data is persisted through object serialization, by wrapping all business operations into command objects, serializing commands and all contained business objects into a log file, and executing them.
Then, when the system recovers after shutdown, all commands are read from the serialized log and executed again, recreating a perfect replica of the system prior to its shutdown.
This makes your system (and all its business objects):

• Persistent, thanks to object serialization.


• Transactional, because each command represent a single transaction and is executed in isolation.


• Incredibly fast!

This is just a short (and partial) introduction: more details can be found here and here.

Prevayler is a Java, Open Source, implementation of a framework for achieving system prevalence.
It is widely used in environments where classical persistence solutions are not suitable or unwanted.
Moreover, it is simple to use, but requires you to sligthly change the way you code your application, because:

• Many applications use the well-known Data Access Object (DAO) pattern for implementing persistence layer logic, while Prevayler (as the prevalence concept dictates) uses plain command objects and requires you to wrap your business methods with them, removing the need of a pure data access layer.


• You have to care about the infamous baptism problem.

The Spring Prevayler-Template project aims at solving these problems, by providing a Prevayler-based implementation of the DAO pattern and the Spring Data Access architecture used for ORM frameworks, which let you create a prevalence system with totally transparent business objects persistence by simply respecting the rules above, common to all prevalence systems, and by:

• Adding an (automatically managed) identifier property to your business objects.


• Implementing a standard Data Access Object, as you would do with Hibernate or alike.


• Configuring it into the Spring application context.

No additional code, no mappings, no annotations ... nothing more.

Let me show you a concrete example.

First, take a bunch of business objects, say a Person, an Employee and a Company:

public interface Person extends Serializable {
  
  public void requestEmployment(Company company);
}


public interface Employee extends Person {
  
  public void workAsAMad();
}


public interface Company extends Serializable {
  
  public void employ(Person person);
}

Then, implement your business objects and assign them a simple identifier property:

public class PersonImpl implements Person {
  
  private Long id;

  public void requestEmployment(Company company) {
    // ...
  }
}


public class EmployeeImpl implements Employee {

  private Long id;
  
  public void workAsAMad() {
    // ...
  }
}


public interface CompanyImpl implements Company {
  
  private Long id;

  public void employ(Person person) {
    // ...
  }
}

That's all you need to do with your business objects.

Now, let us write a Data Access Object using the PrevaylerTemplate.
The classes showed below are a Prevayler-based porting of the well-known Hibernate generic DAO:

public interface IGenericDao<T, PK extends Serializable> {
    
    public PK create(T newEntity);
    
    public void update(T entity);
    
    public void delete(T entity);
    
    public T read(PK id);
}


public class PrevaylerGenericDao<T, PK extends Serializable> implements IGenericDao<T, PK> {
   
    private PrevaylerTemplate prevaylerTemplate;
    private Class<T> entityType;
   
    public PrevaylerGenericDao(Class<T> type) {
        this.entityType = type;
    }
    
    public PK create(T newEntity) {
        this.prevaylerTemplate.save(newEntity);
        return (PK) newEntity.getId();
    }
    
    public void update(T entity) {
        this.prevaylerTemplate.update(entity);
    }
    
    public void delete(T entity) {
        this.prevaylerTemplate.delete(entity);
    }
    
    public T read(PK id) {
        return (T) this.prevaylerTemplate.get(this.entityType, id);
    }

    public PrevaylerTemplate getPrevaylerTemplate() {
        return prevaylerTemplate;
    }

    public void setPrevaylerTemplate(PrevaylerTemplate prevaylerTemplate) {
        this.prevaylerTemplate = prevaylerTemplate;
    }
}

As you may note, the PrevaylerTemplate is used as it were a standard, maybe Hibernate based, data access template.

Finally, you need to configure it:

<bean name="prevalentSystem" class="org.springmodules.prevayler.system.DefaultPrevalentSystem">
    <property name="prevalentClasses">
        <list>
            <value>Person</value>
            <value>Company</value>
        </list>
    </property>
</bean>
    
<bean name="prevaylerConfiguration" class="org.springmodules.prevayler.configuration.PrevaylerConfiguration">
    <property name="prevalentSystem" ref="prevalentSystem"/>
    <property name="prevalenceBase" value="classpath:testPrevalenceBase"/>
</bean>

<bean name="prevaylerTemplate" class="org.springmodules.prevayler.PrevaylerTemplate">
    <property name="configuration" ref="prevaylerConfiguration"/>
</bean>

There are just three objects to configure:

• The prevalent system, defining the prevalent system implementation to use for storing your business objects. It requires you to configure the list of prevalent classes in the system, that is, the classes of business objects to persist. Note that if you need to persist a whole hierarchy, you need to specify just the base class, as it is in the sample where we configured just the Person class.
  


• The prevayler configuration, defining the prevalent system implementation to use, and the location of the directory where Prevayler logs will be saved.


• The prevayler template, defining its associated configuration bean.

That's all ... now your business objects are ready to be persisted!
And if you need to persist a new business object, just add its class to the prevalent classes configuration and do no more!

Prevayler-Template is a new born Spring module, currently available here into Spring Modules sandbox.
You can also take a look at Prevayler-PetClinic, the Prevayler-Template sample based on the well known PetClinic web application: you can find it here.

Any feedback is highly appreciated: feel free to comment on this post, or to ask a question through the Spring Modules forum.

Have fun!

Spring 2.0 and Maven 2

And finally, the happy ending: Spring 2.0 is in the Maven 2 repository!

This is a great gift for the whole (rich) Maven 2 community.

My best congratulations to Ben Hale and the whole Spring team!

Great news about Spring

Hi all,

there are great news in the air about the Spring Framework.

I think all of you know that the final 2.0 version has been released yesterday, but you may not know that Spring 2.0 will be published into the official Maven2 repository in the next days: take a look here.
That's great!

In the meantime, Spring Modules 0.6 has been also published yesterday into Maven2 repository: that's great, too!

Stay tuned!