struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Tomcat/Struts/XML/XSL
Date Mon, 12 Jun 2000 19:23:21 GMT
Kevin Duffey wrote:

> 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?
>

You just gave one of the answers to your own question :-).

Tomcat+Apache serves static pages quite a bit faster than Tomcat standalone.
Whether it is significant in your application depends on your app requirements.

Another reason you might want to stay integrated with Apache is that you've got
other dependencies on functionality provided by Apache that is not in Tomcat
(CGI scripts, server side includes, PERL or PHP stuff, and so on).

If you don't need any of that, and the performance issue isn't relevant, it is
certainly simpler to deploy Tomcat standalone.

>
> > 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 members..so 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.
>

Yes, I met Karl at JavaOne.  He's a smart guy!

I'm not familiar with how Orion does the "filtering" you are talking about
specifically, but just controlling access is a standard feature of the Servlet
2.2 API and will be portable across servlet containers -- which was why I was
gently discouraging you from implementing access control yourself.  Any
container-specific facility (such as request interceptors in Tomcat, or Valves
in Catalina) are going to be just that -- tied to the features of a particular
container.

>
> > 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.
>

One of the speakers on Friday described a system that supports a lot more
activity than that, with a bunch of Apache front ends, a bunch of middle tier
machines with Apache JServ and an EJB server, and a mongo database back end.  I
can guarantee you that the URLConnection approach would not scale to that kind
of volume :-).

>
> >
> > * 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.
>

You might do best to ask this "how to" question on a Cocoon-specific mailing
list.

>
> >
> > * 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.
>

Um, err, but you cannot separate the "start" and "end" of a custom tag across
multiple files.  They need to be in the same one.  (JSP 1.1 spec, section
2.1.3).

>
> > * 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 ;)

Actually, it probably isn't feasible.  The servlet 2.2 spec requires you to pass
the request and response objects you originally received to any
RequestDispatcher.include() that you use to get the content, so it's not
possible to do the wrapping you need.


>
> > * 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
> portable.
>
> > 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?
>

Well, since it's not my application, I'd either wait for the 2.3 spec :-), or
implement the nested tag approach.

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

Goes with the territory if you want to convert XML to HTML!

>
> >
> > 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.

Craig



Mime
View raw message