struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leslie Yu" <>
Subject Re: Is Struts suitable for Java client?
Date Wed, 14 Aug 2002 22:09:00 GMT
I'm using WebSphere Application Server 4.0.x which only supports J2EE1.2. As
I know, Filter is not supported in J2EE1.2 (i.e. Servlet 2.2). Any other
idea? Thanks.

----- Original Message -----
From: "Jason Chaffee" <>
To: "Struts Users Mailing List" <>
Sent: Tuesday, August 13, 2002 11:54 PM
Subject: RE: Is Struts suitable for Java client?

Probably the best thing to do would be to use a filter.  The filter could
handle the serialized object and do any preprocessing that the controller
servlet would need.

-----Original Message-----
From: Leslie Yu []
Sent: Wednesday, August 14, 2002 2:50 PM
To: Struts Users Mailing List
Subject: Re: Is Struts suitable for Java client?

Hi all,

    Thank you so much for your replies. I have one more question about the
java client and server communication in Struts.
Can I send serialized object from java client to the controller servlet?
After studying the Struts documentation, I get an idea that the ActionForm
class will only capture the HTML form field values from the
HttpServletRequest. And the Action class will get the data from the
ActionForm. Does it mean that in order to let the java client talk to the
controller servlet successfully, we need to simulate the HTML form POST
action in the client? Can the Action class receive a serialized object sent
from the client?
    Thanks in advance.

Best regards,

----- Original Message -----
From: "Craig R. McClanahan" <>
To: "Struts Users Mailing List" <>
Sent: Tuesday, August 13, 2002 9:53 PM
Subject: Re: Is Struts suitable for Java client?

> On Wed, 14 Aug 2002, John Yu wrote:
> > Date: Wed, 14 Aug 2002 12:25:02 +0800
> > From: John Yu <>
> > Reply-To: Struts Users Mailing List <>
> > To: Struts Users Mailing List <>
> > Subject: Re: Is Struts suitable for Java client?
> >
> > You can return binary data from the Actions. In the action's
> > perform()/execute(), instead of returning a forward mapping, what you
> > do is:
> >     * Set the correct content type and header by calling
> > response.setContentType() and setHeader()
> >     * Get the output stream from response.getOutputStream() and stream
> > whatever binary data you need to return
> >     * at the end of the perform()/execute() method, return null.
> John is spot on in describing the mechanics of meeting this need.  A
> little more background information on why Struts works this way might be
> useful to you, and to others considering web "applications" that do not
> emit HTML directly.
> The general MVC model that Struts encourages is to have your Action
> perform the business operations related to a particular request, but not
> to get involved in creating the actual response.  Instead, the normal
> pattern is to forward to some other resource in the webapp (typically, but
> not necessarily, a JSP page).  For example, you can forward to a servlet
> that produces binary output.
> However, Struts does not *force* you to take this approach.  In general,
> returning null from your Action.perform() or Action.execute() method says
> "I have already taken care of producing the response -- there is no need
> for any further processing".
> Some example scenarios where this might be better than forwarding to a
> different resource to produce the response content:
> * Your Action decides that a redirect to some other (internal or
>   external) URL is appropriate.  If the Action has called
>   response.sendRedirect(), you don't need or want to have some other
>   webapp resource try to create a response that isn't going to be seen
>   in any event.
> * Your Action is creating a dynamic image (such as the graph from a
>   live stock price tracking application -- although for most stocks,
>   including SUNW (my employer), I don't really want to see the recent
>   graphs, thank you :-).  If your Action writes the binary data for this
>   graph directly to the response, there is no need for a separate
>   resource to produce it.
> * Your action is creating a response stream containing a serialized
>   Java object (such as when you are talking to an applet).  If your
>   Action does this directly, you won't want to forward to a JSP page
>   anyway -- the response has already been created.
> * Your Action creates a response that is going to be transformed by a
>   Filter before being returned to a client (such as the common scenario
>   where your Action returns XML data that will be transformed by a Filter
>   depending on what kind of client device is making the request).  This
>   will be a common scenario when the business logic of your application
>   wants to create XML data in some standardized format that is transformed
>   into browser-specific (or wireless-device-specific) HTML or WML by an
>   external filter.  (Note that you can still use a JSP page to do this
>   sort of XML output with interspersed dynamic output via custom tags;
>   the point is that you might be rendering the output from something like
>   an XML DOM tree that is dynamically generated by your Action).
> (Broad hint for a future direction for Struts -- would you like to create
> Struts-based applications that can make their underlying information
> available via both interactive apps as HTML, and web services using SOAP
> formats?  And be interoperable with JAX-RPC?  I would like that also.
> Stay tuned ...)
> Craig McClanahan
> > At 01:09 pm 13-08-2002, you wrote:
> > >Hi all,
> > >
> > >     I'm going to develop a java application with java client on client
> > >which talks to a controller servlet. The data transmitted between
client and
> > >server may be serialized object.
> > >     Does Struts support java client by outputting a serialized object
as a
> > >HTTP response instead of forwarding to a JSP? If yes, would anyone give
> > >some hints? Thanks.
> > >
> > >Best Regards,
> > >Leslie
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > >For additional commands, e-mail:
> >
> > --
> > John Yu                       Scioworks Technologies
> > e:         w: +(65) 873 5989
> > w:   m: +(65) 9782 9610
> >
> > Scioworks Camino - "Don't develop Struts Apps without it!"
> --
> 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