struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zammetti" <>
Subject Re: Struts Web Services Enablement Project
Date Sun, 06 Jun 2004 23:38:51 GMT
You raise some good points, as have a lot of people on the list.  I keep 
coming back to the same bottom-line point though... Most of the suggestions 
get into something alot bigger than I started with, and that's a good thing, 
but I'm not sure I'm ready to tackle it myself yet.

I think the one underlying point that is coming through is that there seems 
to be a desire, maybe even a need, for a "real" Web Service capability built 
in to Struts.  There's been a lot of different ideas about what form it 
should take, what capabilities are important, and how it should ultimately 
be implemented.  If for no other reason, I think bringing that point to 
light (if it wasn't already!) was a good result of my little project.

But, when I examine where I am now, how I've personally chosen to do things, 
and I ask the question of whether I think it could really be the basis for a 
grander vision, I think I lean towards the answer being no.  I think I've 
put forth a couple of decent ideas, maybe shown people a way to do things 
that is if not original than maybe not a common method, but I don't for a 
second think it's the be-all and end-all of Web Services in Struts, and I 
suspect it probably never could be.

So, in the short-term, my little package can probably be useful to some 
folks, and that's cool.  Over a relatively short period of time I can 
probably expand it and polish it so it's useful to even more people, and 
maybe even be useful enough and polished enough to be included in the Struts 
distro at some point.  But to turn into a whole generally useful to everyone 
Web Service component of Struts?  My gut says no, so I'm a bit hesitant to 
start down that road, especially considering how much I frankly have to 
learn myself to go down that road.

What I do wonder though is if we're coming to a point where maybe we can get 
some people together and start a Struts sub-project (or whatever the proper 
terminology would be) to really do something more capable?  I don't think I 
can pull off something like that alone, not short-term anyway, but I'd 
certainly be interested in being a part of such an effort.  So, does anyone 
else see that as a viable thing to do, and if so, how do we go about 
actually doing it?


>From: robert burrell donkin <>
>Reply-To: "Struts Developers List" <>
>To: "Struts Developers List" <>
>Subject: Re: Struts Web Services Enablement Project
>Date: Sun, 6 Jun 2004 08:54:26 +0100
>On 4 Jun 2004, at 22:56, Frank Zammetti wrote:
>>After that, I'm thinking that a .04 release maybe a week later seems 
>>reasonable, and with that my main goal is implementing the pre- and 
>>post-transformations suggested here.  I haven't thought this through yet 
>>entirely, but what I think this amounts to is not much more than adding an 
>>xslt-in and xslt-out attributes to the mappings in webservices-config.xml 
>>that, if present will trigger processing of the incoming and outgoing XML 
>>via these transformations.  The incoming side of things seems relatively 
>>straight-forward to me, but the outbound side I can't see as clearly right 
>>now because as it currently stands, a JSP renders the XML, so how can I 
>>run the resultant XML through an XSL transformation and return the result 
>>to the client?  One possibility is a new class that would create the XML 
>>and THEN run it through the transformation.  In addition to that, I would 
>>probably add an attribute to the <service> mappings that would specify 
>>whether a JSP is going to render the output, or it will be the result of a 
>>transformation.  This is just rough thinking at the moment, at least as 
>>far as the outbound side goes.
>1 if you want inspiration about pipelining, then take a look at cocoon: 
>they've been successfully doing this kind of thing for years!
>2 the problem with transformations is that (if you want to make them 
>perform), the framework needs to be build with them in mind. typically, 
>this means using something like a SAX pipeline.
>3 using a SAX pipeline restricts the choice of object-xml binders that can 
>be used. having a choice is object-xml binders is important.
>4 IMHO the most elegant solution would be to replace the entire rendering 
>layer (jsp's etc) with a configurable component-based object-xml 
>lightweight binding framework. the actions take and produce objects which 
>are then rendered to and from xml by the framework. any transformations 
>should be done within this layer rather than without allowing different 
>components to support them in different ways (or not at all).
>- robert
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!

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

View raw message