> It seems a bit convoluted: a Filter works explicitly on a HTTP request; not > on a derviate like SOAP. It's probably easier to create a protocol handler > specific to each protocol, and have that handle the call to an ActionBean.
I did not explain myself well. The filter might do nothing at all with the information in the request, though it might have to handle the authentication part. That aside, all it would do is package up the request content so that an ActionBean written to handle it would be coded to accept one (or more, I guess) FileBean parameters. The ActionBean would be responsible for interpreting and acting on the request content. For my application it is likely to be the case that only one protocol would ever exist, at least for the authentication. On another application (servlet-based) the authentication header is universal, while the "protocol" (file formats for uploads, request formats for downloads) may indeed vary. My feeling here is that the filter itself would only pay attention to the authentication header, and then package up the rest of the request's content as a single file parameter. (It's true that if the protocol/format had some file separator semantics that the filter would have to know that. I have in mind that the filter would use some URL pattern queues to make decisions about things like that.) Thanks for your response; it is definitely the case that I may be terribly wrong :) -- Turtle, turtle, on the ground, Pink and shiny, turn around. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
