You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ralph Schaer <sc...@ess.ch> on 2000/06/12 16:46:40 UTC
Re: Struts project not on apache site.
>Can someone at apache put the Struts link on the http://java.apache.org/
>site? I don't see it there as one of the projects.
Struts is part of the Jakarta Project: http://jakarta.apache.org
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> No. The rule is that the start and end tags need to be in a
> single ***file***
> not a single ***page***.
Dang..that blows. ;) Well..back to the drawing board on that issue.
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> No. The rule is that the start and end tags need to be in a
> single ***file***
> not a single ***page***.
Dang..that blows. ;) Well..back to the drawing board on that issue.
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> > 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 :-).
>
> Interesting. But, if URLConnection does the same thing as a web browser
> does..why would it be so slow? I thought it basically creates the request,
> sends it to the server as if a browser did, and the response is sent back as
> the string contents. Is this a fault of the URLConnection class..itself is
> generally slow?
>
It's not just an issue of slow.
What you're doing with a URLConnection is doubling the number of network
connections necessary to respond to a request (one from the original client to
your servlet, and one from your servlet to get the XML output). Simultaneous
threads and sockets are places where lots of OSs have scalability issues. They
are scarce resources that you don't want to squander.
In addition, the HTTP implementation of URLConnection itself is no speed demon
(at least < JDK 1.3, where the release notes say they have implemented
HTTP/1.1).
> [snip]
>
> > 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).
>
> I include them with the @include..so it would all be contained in one
> JSP/servlet, not using the <jsp:include..> directive. That still wouldn't
> work?
No. The rule is that the start and end tags need to be in a single ***file***
not a single ***page***.
>
> Take care.
Craig
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> > 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 :-).
>
> Interesting. But, if URLConnection does the same thing as a web browser
> does..why would it be so slow? I thought it basically creates the request,
> sends it to the server as if a browser did, and the response is sent back as
> the string contents. Is this a fault of the URLConnection class..itself is
> generally slow?
>
It's not just an issue of slow.
What you're doing with a URLConnection is doubling the number of network
connections necessary to respond to a request (one from the original client to
your servlet, and one from your servlet to get the XML output). Simultaneous
threads and sockets are places where lots of OSs have scalability issues. They
are scarce resources that you don't want to squander.
In addition, the HTTP implementation of URLConnection itself is no speed demon
(at least < JDK 1.3, where the release notes say they have implemented
HTTP/1.1).
> [snip]
>
> > 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).
>
> I include them with the @include..so it would all be contained in one
> JSP/servlet, not using the <jsp:include..> directive. That still wouldn't
> work?
No. The rule is that the start and end tags need to be in a single ***file***
not a single ***page***.
>
> Take care.
Craig
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Yes, I met Karl at JavaOne. He's a smart guy!
Tell me about it..I felt tiny when he started talking! ;)
> 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.
Agreed. If it becomes part of 2.3, that would be great. I think its best to
stick with standards so that its portable..you never know when WebLogic, or
any other server may "disappear" as has many before it.
> 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 :-).
Interesting. But, if URLConnection does the same thing as a web browser
does..why would it be so slow? I thought it basically creates the request,
sends it to the server as if a browser did, and the response is sent back as
the string contents. Is this a fault of the URLConnection class..itself is
generally slow?
Sorry I missed your talk. I was trying to make it to your servlet/jsp one (I
think that is the one I saw your name by). I ended up at some xml/xsl
session, and a few others on web performance, ejb, etc.
I liked the one on threads..it was funny to hear these guys say that even
Gosling was surprised that the threading stuff they implemented..doesn't
work! Supposedly there is a new threading architecture in the works for a
future Java (maybe 1.4 or 1.5) that should be much easier to use, and
actually work! :)
> You might do best to ask this "how to" question on a
> Cocoon-specific mailing
> list.
Bah..its no big deal at this point. I will do so when it becomes an issue
for us.
> 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).
I include them with the @include..so it would all be contained in one
JSP/servlet, not using the <jsp:include..> directive. That still wouldn't
work? I would think it would, because the end result of the <%@ include
file..> at the TOP of the JSP page, and at the bottom of the same JSP page
is a combined single servlet with the included files mixed into one servlet.
I'd be surprised to hear it doesn't work.
Take care.
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
> Yes, I met Karl at JavaOne. He's a smart guy!
Tell me about it..I felt tiny when he started talking! ;)
> 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.
Agreed. If it becomes part of 2.3, that would be great. I think its best to
stick with standards so that its portable..you never know when WebLogic, or
any other server may "disappear" as has many before it.
> 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 :-).
Interesting. But, if URLConnection does the same thing as a web browser
does..why would it be so slow? I thought it basically creates the request,
sends it to the server as if a browser did, and the response is sent back as
the string contents. Is this a fault of the URLConnection class..itself is
generally slow?
Sorry I missed your talk. I was trying to make it to your servlet/jsp one (I
think that is the one I saw your name by). I ended up at some xml/xsl
session, and a few others on web performance, ejb, etc.
I liked the one on threads..it was funny to hear these guys say that even
Gosling was surprised that the threading stuff they implemented..doesn't
work! Supposedly there is a new threading architecture in the works for a
future Java (maybe 1.4 or 1.5) that should be much easier to use, and
actually work! :)
> You might do best to ask this "how to" question on a
> Cocoon-specific mailing
> list.
Bah..its no big deal at this point. I will do so when it becomes an issue
for us.
> 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).
I include them with the @include..so it would all be contained in one
JSP/servlet, not using the <jsp:include..> directive. That still wouldn't
work? I would think it would, because the end result of the <%@ include
file..> at the TOP of the JSP page, and at the bottom of the same JSP page
is a combined single servlet with the included files mixed into one servlet.
I'd be surprised to hear it doesn't work.
Take care.
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
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 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.
> 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
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?
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.
RE: Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
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 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.
> 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
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?
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.
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> Hi,
>
> Probably been answered before..but I have a few questions about the overal
> combo of the subject.
>
> First, is Tomcat a 100% java written application, so it runs on any
> platform?
>
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.
>
> Next, I was reading over Struts, and while everything looks great, I am
> wondering if it is possible to handle XML -> XSLT -> HTML with the
> framework, using cocoon? I don't know how stable the overall platforms are,
> and I know my company is going with WebLogic Server for our enterprise
> solution, but I believe its possible to use Struts and I was hoping I could
> start moving to XML to XSLT to HTML output.
>
> If it is possible, let me ask the Struts team this. If I have an action that
> returns Success/Failure, and in the config file (actions.xml) I have two JSP
> pages, the obvious flow is to forward to one of those two JSP pages. Is
> there any way to use an XML page instead, (if thats how it is done), and
> have the XML routed through the XSLT engine, supplying an XSL stylesheet for
> the transform, and have the response go back with the transformed html?
>
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.
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.
>
> If not, I was wondering if this could be implemented in Struts, or for that
> matter, is anyone already doing this? I started my own framework based on
> the talks we had in jsp-interest with Craig and Daniel and a number of
> others (Model 2 discussions). My thought was, have the JSP page return XML
> (by setting the header to text/xml), and in the controller servlet, instead
> of forwarding to a JSP page, it would get a URL, read in the JSP page (into
> a stringbuffer), which would be XML formatted (because of the setHeader()
> call to use xml output), and then pass that through the cocoon servlet. I
> haven't seen cocoon yet, but I assume it returns the "transformed" content
> back to whoever calls it. Thus, the last part of the controller servlet
> would be to fill the response object with this content..so that it goes back
> to the browser.
>
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.
* 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.
* 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.
* 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.
* 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.
>
> Does this seem feasible..or even possible? If so, is this the right approach
> to take, or is there something already in the works to make all this work.
>
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.
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.
>
> Thanks.
Craig
Re: Tomcat/Struts/XML/XSL
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Kevin Duffey wrote:
> Hi,
>
> Probably been answered before..but I have a few questions about the overal
> combo of the subject.
>
> First, is Tomcat a 100% java written application, so it runs on any
> platform?
>
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.
>
> Next, I was reading over Struts, and while everything looks great, I am
> wondering if it is possible to handle XML -> XSLT -> HTML with the
> framework, using cocoon? I don't know how stable the overall platforms are,
> and I know my company is going with WebLogic Server for our enterprise
> solution, but I believe its possible to use Struts and I was hoping I could
> start moving to XML to XSLT to HTML output.
>
> If it is possible, let me ask the Struts team this. If I have an action that
> returns Success/Failure, and in the config file (actions.xml) I have two JSP
> pages, the obvious flow is to forward to one of those two JSP pages. Is
> there any way to use an XML page instead, (if thats how it is done), and
> have the XML routed through the XSLT engine, supplying an XSL stylesheet for
> the transform, and have the response go back with the transformed html?
>
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.
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.
>
> If not, I was wondering if this could be implemented in Struts, or for that
> matter, is anyone already doing this? I started my own framework based on
> the talks we had in jsp-interest with Craig and Daniel and a number of
> others (Model 2 discussions). My thought was, have the JSP page return XML
> (by setting the header to text/xml), and in the controller servlet, instead
> of forwarding to a JSP page, it would get a URL, read in the JSP page (into
> a stringbuffer), which would be XML formatted (because of the setHeader()
> call to use xml output), and then pass that through the cocoon servlet. I
> haven't seen cocoon yet, but I assume it returns the "transformed" content
> back to whoever calls it. Thus, the last part of the controller servlet
> would be to fill the response object with this content..so that it goes back
> to the browser.
>
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.
* 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.
* 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.
* 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.
* 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.
>
> Does this seem feasible..or even possible? If so, is this the right approach
> to take, or is there something already in the works to make all this work.
>
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.
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.
>
> Thanks.
Craig
Tomcat/Struts/XML/XSL
Posted by Kevin Duffey <kd...@buymedia.com>.
Hi,
Probably been answered before..but I have a few questions about the overal
combo of the subject.
First, is Tomcat a 100% java written application, so it runs on any
platform?
Next, I was reading over Struts, and while everything looks great, I am
wondering if it is possible to handle XML -> XSLT -> HTML with the
framework, using cocoon? I don't know how stable the overall platforms are,
and I know my company is going with WebLogic Server for our enterprise
solution, but I believe its possible to use Struts and I was hoping I could
start moving to XML to XSLT to HTML output.
If it is possible, let me ask the Struts team this. If I have an action that
returns Success/Failure, and in the config file (actions.xml) I have two JSP
pages, the obvious flow is to forward to one of those two JSP pages. Is
there any way to use an XML page instead, (if thats how it is done), and
have the XML routed through the XSLT engine, supplying an XSL stylesheet for
the transform, and have the response go back with the transformed html?
If not, I was wondering if this could be implemented in Struts, or for that
matter, is anyone already doing this? I started my own framework based on
the talks we had in jsp-interest with Craig and Daniel and a number of
others (Model 2 discussions). My thought was, have the JSP page return XML
(by setting the header to text/xml), and in the controller servlet, instead
of forwarding to a JSP page, it would get a URL, read in the JSP page (into
a stringbuffer), which would be XML formatted (because of the setHeader()
call to use xml output), and then pass that through the cocoon servlet. I
haven't seen cocoon yet, but I assume it returns the "transformed" content
back to whoever calls it. Thus, the last part of the controller servlet
would be to fill the response object with this content..so that it goes back
to the browser.
Does this seem feasible..or even possible? If so, is this the right approach
to take, or is there something already in the works to make all this work.
Thanks.
RE: Struts project not on apache site.
Posted by Kevin Duffey <kd...@buymedia.com>.
Thanks.
> -----Original Message-----
> From: Ralph Schaer [mailto:schaer@ess.ch]
> Sent: Monday, June 12, 2000 7:47 AM
> To: struts-user@jakarta.apache.org
> Subject: Re: Struts project not on apache site.
>
>
>
> >Can someone at apache put the Struts link on the http://java.apache.org/
> >site? I don't see it there as one of the projects.
>
> Struts is part of the Jakarta Project: http://jakarta.apache.org
>
>