struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeromy Evans <>
Subject Re: [S2] Splitting a Struts 2 Application
Date Thu, 06 Dec 2007 00:18:52 GMT
Skip Hollowell wrote:
> This may be a bit off target, but I was hoping some folks here have 
> some suggestions.
> I have been working on a Struts2 app here for the last6-8 months, and 
> it is now pretty stable.  So stable in fact that we want to use it as 
> a model for more apps with similar functionality.  So my question is, 
> how can I split this thing apart, presumably into Core features, and 
> project specific features.
> I assume I will keep a separate set of JSP's for each app.  But what 
> about actions?  I can keep the struts jar files, and the base actions 
> in the core project.  And then...what?  Extend those actions as needed 
> for features outside of the core set on a project by project basis?  
> All of my file and XML processing for example, can be core.  But each 
> of my actions extends the, which in turn is 
> used to load all of my  So do I somehow tell 
> it to use a properties file from my project dir instead?  How?
> You can see my confusion, and my dilemma.  I am just trying to set 
> things up now so I am not maintaining multiple copies of code for the 
> core features of all of these apps, and most of these core feature are 
> very Struts2 related.
> Any help, pointers, wikis or articles that you know of would be 
> greatly appreciated.
> Skip.
Hi Skip,
Here's some tips:

1. Refactor common business logic out into its own re-usable jar(s).  
This should have no struts dependency whatsoever.  Build upon this and 
refactor as it grows and you'll end up with code you can reuse across 
your applications.  These should be common classes, services, mixins and 
helpers that your actions and other applications can reuse.

2. Your common actions, result types, interceptors, validators etc can 
all be refactored into jar(s).  Struts2 will allow you to use any of 
these if they're referenced in your config and available in your app's 

3. Unfortunately JSP's cannot be loaded from the classpath and this is 
an important reason many developers prefer Freemarker or Velocity 
pages.  Your JSP's will need to be duplicated for each webapp (you could 
make this part of the build process though).  If you are genuinely going 
to reuse pages and or components, consider converting them to Freemarker 
or Velocity as don'e for all the struts UI tags.  This approach also 
allows them to be unit tested easily and potentially reused in other 

4. Depending on what you're re-using, it may be beneficial to create 
your own struts2 plugin that sets up your re-usable default stack, 
interceptors, default results, etc.  This is surprising 

5. Finally, strongly resist the temptation to create a deep action class 
hierarchy.  If you genuinely have common simple behaviour, sure, create 
your own ActionSupport equivalent, but otherwise try following the 
patterns already used in struts2: Simple and shallow pojo actions.  eg. 
create your own interfaces like ValidationAware, SessionAware etc. for 
your actions (eg. I use EmployeeAware) and create delegates, mixins or 
services for the common behaviour.  Don't allow unused superclass 
behaviour to get into your action classes as it may bite you later.  
Keep them nice and simple.

Hope that helps,
Jeromy Evans

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

View raw message