struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: Should I announce SmartURLs or wait?
Date Tue, 11 Sep 2007 15:33:30 GMT
Ted Husted wrote:
> On 9/11/07, Brian Pontarelli <> wrote:
>>  If we keep it a plugin then I would suggest removing zero-config from core
>> so that they don't conflict. I'd probably also want to rework the
>> DispatcherFilter to make it more pluggable so that the majority of the work
>> is from injections and then it can be changed without modifying the web.xml.
>> Lastly, the configuration providers need to be easier to setup. This would
>> probably require a more robust configuration mechanism that would pre-inject
>> configuration providers and then inject the rest of the container.
> I think this is the strongest argument for plugging in as much as
> possible ourselves. If we can do it, then someone else can do it too!
> Don put in the plugin architecture less than a year ago, and our first
> stable release was only four months ago. Already, we have a couple of
> dozen plugins, including SmartURLs, and we're learning how to extract
> other functionality like Ajax and Portlets into plugins too.
> I'd say we should continue to exploit the plugin architecture, so that
> Struts becomes a lightweight core adorned with plugins. We should
> encourage people to think of Struts plugins they way we think about
> Eclipse or Maven plugins.
I do think this sounds pretty good. I like the plugin architecture, but 
it needs more functionality and extensibility to make it a complete 
solution. Right now not enough of the core infrastructure is exposed to 
plugins and it is difficult to make things just drop in and work.

I think it can be done, it just needs some good discussion and some 
changes to core.

>>  However, all that said, I think this should be in core. The beauty of
>> frameworks like Rails and Grails is that they give all the conventions right
>> out of the box. I feel like Struts should try to strive to match the ease of
>> these other frameworks. Otherwise, it requires the users to actually know
>> that the plugin exists, go find it, install it and then learn it all.
> I'd say it's way too early to say we've hit the best and brightest way
> to do this. (Or that Rails or Grails has either!)
> If we starting rolling things like this into the core, then as you
> pointed out, we start to foreclose possibilities for alternate
> plugins, or at least make it harder for other people to innovate.
> There is a lot more to Rails or Grails type functionality than zero
> configuration and code behinds. To really do "Struts on Rails", we'd
> need to encourage people to use Maven prototypes to create starter
> applications, which could easily include items like the CodeBehind 2
> plugin, along with starter actions and pages, test cases, and so
> forth. We also need to think about items like Hibernate or iBATIS
> plugins.
I'll definitely agree on that point. In fact I've already started work 
on a system just like the one you describe. However, I selected the 
frameworks and unlike systems like AppFuse, I decided to not give 
choices for frameworks, but give more functionality. It's called Vertigo 
and it contains an entire build system with project creation (based on 
Ant and Savant for dependencies), database migrations, emailing via 
FreeMarker and concurrency utils, environment aware configuration with a 
hierarchy, injection via guice, JPA support, security (via ACEGI, which 
does require Spring, but that will soon be refactored), common actions 
like country drop downs, ECommerce transactions (currently only via, a good set of domain classes and base classes, and more 
is being added all the time.

Take a look if you guys get a chance:

> One compromise would be to keep CodeBehind/ZeroConfig as a plugin, in
> its own JAR, but to ship it in the struts-lib distribution, and make
> it a standard part of any applications or prototypes we offer. People
> won't have to go and get it, because it will already be there. But, if
> someone wants to try something different, they can pluck it out.
I like this the best. I think Struts should have a standard convention 
based system that comes with the distribution and is part of the core 
documentation. Folks that don't want it, just yank the JAR out of 
WEB-INF/lib. Those that want it, have it. I think the key is to have it 
as part of the core documentation so that folks know about it up front.


View raw message