struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject RE: Shale <--> Struts 1.n
Date Tue, 01 Feb 2005 21:32:29 GMT
On Tue, 01 Feb 2005 11:09:22 -0800, Michael Oliver wrote:
> Well Ted, Craig certainly wasn't singing that tune, although that
> doesn't mean you are wrong either.

Craig believes that Shale is the best way to write new web applications for Java. And he may
be right.

But, I don't think Craig is suggesting that thousands and thousands of teams all over the
world should stop everything and migrate perfectly good Struts applications to Shale. :)

For the past five years, we've been saying that Struts and MVC are cost-effective because
it makes web applications cheaper to *maintain*. Now, that so many of us have our application
in cheap maintenance mode, it would be silly to suggest people are suppose to fix things that
aren't broken. 

Just because Shale might be a better way to write *new* applications, it doesn't mean existing
applications are suddenly obsolete. Obsolete means it would be cheaper to rewrite it than
to maintain it. I doubt that anyone is suggesting that it would be cheaper to rewrite a stable
application in Shale rather than maintain it in Struts.

If a poorly-written Struts 1.x application were due for a major upgrade, sure, *someday* it
might be cheaper to rewrite in Shale. But a well-written Struts 1.x application is still going
to enjoy a long lifecycle. And, probably several upgrades, as there is worked planned for
Struts 1.3, 1.4, 1.5, 1.6, and so on. :)


> As you and I discussed back when we tried to solve the problem of
> opening existing Struts applications to Axis/SOAP with Axis4Struts
> so a SOAP Actor can be just another View into Struts Applications,
> it would seem natural for Shale to have at least some vestige of
> interoperability, be that some interfaces or some "gateway"
> Actions, so the baby of existing production Struts Applications can
> take advantage of JSF/Shale without being thrown out with the
> bathwater.

Web platforms are very flexible, and Java platforms doubly so. I've mixed and matched workflows
with things like Struts and Maverick, and I'm sure you could do them with Struts and Shale
too. Or Shale and Tapestry. Or name any combination of frameworks. :) 

Web services are a horse of a different color. But, as far as mixing-and-matching web frameworks
goes, it would not sound like a good long term solution. 

The key advantages of Shale are best realized by new development.

But, since Shale is unreleased software, the better place to discuss such things would be
the dev@ list. 


> Michael Oliver
> Alarius Systems LLC
> 3325 N. Nellis Blvd, #1
> Las Vegas, NV 89115
> Phone:(702)643-7425
> Fax:(520)844-1036
> *Note new email changed from
> -----Original Message-----
> From: Ted Husted []
> Sent: Tuesday, February 01, 2005 10:41 AM
> To: Struts Users Mailing List
> Subject: Re: Shale <--> Struts 1.n
> On Tue, 01 Feb 2005 09:44:43 -0800, Michael Oliver wrote:
>> What are the plans for migration and/or interoperation for Shale  
>> and Struts 1.n?
> There's been some talk on the dev list about using both frameworks
> together, on a temporary basis, but it's not recommended.
> It's a lot like asking what are "our plans for migration and/or
> interoperation for Tapestry and Struts 1.n?"
> They are two different frameworks, and there really isn't much
> reason for them to interoperate.
> Eventually, after Struts Shale ships, I'm sure people who migrate
> applications from other frameworks will beat a path and document
> some tips.
> But, right now, Shale is seen as a tool for new development for
> teams standardizing on JavaSererFaces, not as a successor to Struts
> 1.x.
> Like everyone else, most of the committers have significant Struts
> 1.x applications in production and see no reason to migrate them
> anytime soon.
> -Ted.
>> Michael Oliver
>> CTO
>> Alarius Systems LLC
>> 3325 N. Nellis Blvd, #1
>> Las Vegas, NV 89115
>> Phone:(702)643-7425
>> Fax:(520)844-1036
>> *Note new email changed from
>> ------------------------------------------------------------------
>> --  - To unsubscribe, e-mail:
>> For  additional commands, e-mail:
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: For
> additional commands, e-mail:
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: For
> additional commands, e-mail:

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

View raw message