struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Duffey" <>
Subject RE: Tomcat/Struts/XML/XSL
Date Mon, 12 Jun 2000 19:12:09 GMT
Hi Craig, (and list)

> When you run Tomcat standalone, it is 100% Java and runs on any
> platform with an
> appropriate JDK (currently 1.1 or higher).
> When you run Tomcat connected to a web server (Apache, iPlanet,
> or Microsoft),
> you need a connector module written in C that actually does the
> integration with
> the webserver.  This code is (by necessity) platform specific.
> The C source is
> provided so that you can compile it for your platform, and
> pre-built modules for
> several common platforms is available as well.

Very kewl. Now..I hate to ask this..but if Tomcat is built by the same team
(or members of) that built Apache (is this so?), why would you not just run
Tomcat without Apache? What is Apache used for in this case..since Tomcat
has its own webserver, and can run by itself. Also, is tomcat "faster" at
serving pages than Apache is?

> Note -- I responded in a message last night with how to have more than two
> ("success" and "failure") destinations if you need them, by extending the
> ActionMapping class to include additional properties.

Yes..thank you. I did get that. I hope I wasn't reitterating the same thing.

> Routing of output from a JSP page (in this case) through some
> other processing
> is not currently a feature of the servlet API.  Some servers have
> implemented a
> thing called "servlet chaining" that does this, but the design is
> fraught with
> problems and is not portable.  Work is ongoing in the expert group that is
> discussing the next version of the servlet specs (will be version
> 2.3) to add
> some sort of filtering capability, with the sort of transformation you are
> talking about as a common use case.

Yeah. Actually, Orion application server does indeed support filtering. Its
the only web/app server I have seen that does this...and its quite nice to
have. The fact that you can have any access to any files in any dir go to a
specific servlet allows for some very powerful security abilities. Such as,
if you don't want people accessing .gif/.jpg images, accept for those
allowed, you can map a servlet to *.jpg and *.gif in a specific dir, and
everything in that dir is filtered through the servlet. You then code to
allow jsp/gif or not. Actually..I could be wrong on how Orion actually
works..but I know it does. Infact, I was talking with the creator of Orion
(I think you know them..I met with Karl during JavaOne and he showed us a
picture of you and some other I assume you know about Orion
Server?), and he mentioned that instead of doing the framework like you have
(and I have been doing), you can do servlet filtering and not even need this
type of framework. Not quite clear on what he meant by this..but I think
instead of mapping .do, you can map anything to a servlet, filter in/out
what you want, etc. Maybe you can elaborate on that if you know about
it..feel free to email me off the list.

> As you have described it, the idea of doing transformations is
> generic to anyone
> using JSP pages, not just those using Struts as their application
> framework.
> Until the next servlet spec makes it possible to do this at the
> container level,
> a couple of approaches to consider:
> * Use a URLConnection to connect to yourself and read the output of the
>   JSP page, presumably in the form of an XML document, and then apply
>   the filter to it.  This is going to have substantial
> performance impacts,
>   but it is feasible.

Lucky for us, at the HEAVIEST load, we would be lucky to have 1000 users on
our site in a 24-hour period, and we are setting up 1Ghz servers with 1GB
memory for our web servers and servlet engines (using WebLogic cluster..I
voted for Orion, but WebLogic is well-known and supported in the industry
thus far..and looks good to VCs and money-backing folks to have a strong
player like WebLogic), so I think the performance hit is ok for us,
especially since we are clustering the servlet container and can use
load-balancing to handle multiple requests.

> * Use Cocoon -- I don't know if you can insert JSP pages in the processing
>   pipeline that Cocoon sets up, but if it is that might be a
> solution.  I will
> need
>   to spend some time looking at that.

Let me know what you find. However, as I have seen done with Orion, you can
specify a JSP page to return XML (assuming you have well-formed html in the
JSP page..which means <br/> or <br></br> tags, etc in the page. Thus, I
could feed cocoon the XML output from the URLConnection (my bad..I said
URL..I forget its URLConnection to read the page in code), which I would
read in to a StringBuffer probably..but again not sure if I can instantiate
cocoon and pass it an xml string for processing, which in turn would return
an string with html (after the xslt transform from xml to html using a
stylesheet), then send that in the response back to the browser.

> * Write a custom tag that you would use to surround all the rest
> of your JSP
>   page (which would then presumably be generating XML instead of HTML).
>   The nested text would then be passed through an XSL stylesheet specified
>   as an attribute; something like this:
>     <struts:xsl stylesheet="xxxxx.xsl">
>         ... original body of your JSP page ...
>     </struts:xsl>
>   This approach has the disadvantage of requiring you to modify every
>   JSP page to include the surrounding tag, but it would be fairly easy to
>   implement.  There is a similar tag in the jakarta-taglibs "xsl"
> library that
>   we can use as a starting point.

interesting. The good news about this approach is that I already include a
HEADER and FOOTER on EVERY jsp page..thus I could merely insert this tag
into each of those .inc files, and case solved.

> * Modify the controller servlet to somehow swallow the output and do the
>   transformation.  This would be a pretty substantial amount of work,
>   because the controller servlet would need to provide a simulated
>   environment to the JSP page so that it could wrap the output.  It will
>   also be obsoleted by the new servlet spec.  But it could probably be
>   done in a portable manner.

Agreed..not a good choice (I take it that is what you are saying ;)

> * Do the transformation in a RequestInterceptor (current Tomcat
> architecture)
>   or Valve (Catalina architecture).  Although this is feasible, it is
>   platform specific instead of being portable.

Yet another "no go" solution in my opinion. It definitely needs to be

> IMHO there is not necessarily only one answer to this.  The
> <struts:xsl> tag is
> certainly easy to build, and I can go ahead and do that one, but
> it's not going
> to solve everyone's problems.

Agreed. How would you have it work? Like you said above..where it passes all
input between the open/close tags to the Cocoon xslt processor?

Ofcourse, this leaves me to figure out how the heck to do a style-sheet for
the xml to html conversion. ;)

> By the way, this whole discusson is more relevant to take place on the
> STRUTS-DEV list since it is talking about what kinds of changes
> to Struts might
> be appropriate (rather than how to use what is already there).
> Therefore, I've
> "cc'd" the STRUTS-DEV list so that the folks not subscribed to
> both lists, but
> might be interested in this discussion, can see it.

My bad..I didn't realize I wasn't talking on the developer list. Sorry about
that. This discussion is geared more towards development anyways. Thanks for
doing that.

View raw message