commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: [chain] Pre-conditions
Date Fri, 20 May 2005 13:17:34 GMT
While I've used an "checkPreconditions" type approach in some of my 
Command implementations, I'm not sure I feel like I've got anything 
I'd want to codify as "best practices" in formal interfaces in 

However, when you suggest annotations, I think that sounds pretty 
interesting and like the right general approach, except that I'm not 
ready to bind commons-chain to Java 5.0 yet.  As you describe it, 
though, one could simply create a deluxe version of a Catalog and/or 
a Chain which enforced those checks.  That seems pretty interesting.

Since we're talking about Chain and futures, here are the two things 
I'm seeing as most interesting directions for improvement:
1) make sure that there are no dependencies on the Digester-based 
bootstrapping.  The more I use the Spring framework, the more I want 
my chains to be able to have their dependencies injected.  I recently 
made some commits that rearrange all calls to 
"CatalogFactory.getInstance()" so that they are only used as a 
fallback, but that there's always a way to set the CatalogFactory as 
a bean property (for example, for a LookupCommand).  There may not be 
a whole lot more work to do here, except for one thing -- as much as 
I like Spring, I find the XML syntax verbose compared to Digester 
based syntax.  I've spent a little time trying to figure out how to 
make a Spring BeanFactory which could somehow read from Digester but 
also handle dependency injection, but I haven't had a whole lot of 
time to get into it.  However, verbose or not, it's entirely possible 
to make commands, chains, and even catalogs in a Spring beans XML 
file, which is a nice alternative.

2) Figure out a way to decorate chains without copying their 
configuration.  Most of my chain work is in the context of Struts, 
where there's a "standard" chain included in the distribution for 1.3 
(as yet unreleased).  However, I am always making a few changes to 
that chain -- it would be nice to be able to apply commands in the 
way that you can apply "preGoal" and "postGoal" behavior in Maven. 
(You could also think of it as an "aspect-oriented" problem.)  I 
haven't spent too much time thinking about this, but partly because I 
haven't had any ideas that seemed promising to pursue.

Sorry to hijack your thread, but now that Chain is pretty stable, it 
seems like a decent time to solicit more ideas for the next steps.


At 2:25 PM +0200 5/13/05, Mattias J wrote:
>I have just started using Jakarta Chains to refactor and evolve an 
>existing project. I've had thoughts around this for a long time, and 
>finally got around to it. When actually working with this 
>API/pattern, a few questions come to mind, mostly related to the 
>dependencies between different Commands in a Chain.
>The post-conditions of a Command should of course be checked using 
>unit tests. But what is the best practice for handling 
>pre-conditions (i.e. context must be of type MyContext, context must 
>contain value for key "myKey", value for "myKey" must be of type 
>Naturally pre-conditions should be documented in the JavaDoc of the 
>Command implementation, but this is not always the best for 
>mainainability and debugging.
>- Should all possible Chain combinations be unit tested?
>- Or would it be an idea to create a sub interface to Command to 
>add, say, checkPreConditions()?
>This could of course done using AOP and configuring aspects via 
>annotations, for example
>   @ContextType(MyContext.class)
>   @RequiredKey("myKey")
>   @ValueType("myKey", MyClass.class)
>- Or maybe one could elaborate this even further, creating rule 
>object sets returned by Commands as pre-conditions and 
>post-conditions, so that a Chain would be responsible of making sure 
>the different Commands are compatible when added using 
>Does anyone else have any thoughts about this?

Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message