Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
Hi Brad!
Brad Cox wrote:
I should point out at the outset that this isn't to assign blame but
to point out a problem... namely, the complexity that developers must
deal with to get a working infrastructure in place. My application
uses Apache, JServ, Java, and the servlet engine from Tomcat. Period.
No taglibs, no JSP, no XML, nothing. Yet it took a whole week to get
even this on the air, even though I've been through the tomcat
configuration process dozens of time by now and had working config
files to start with.
I'm about to answer in Jon's favorite manner (hope you don't mind, Jon):
Ok, it seems to be a problem. Why don't you fix it?
Next problem was various JServ failures, none clearly explained by
the errors, and none explaining what what was wrong and how to
correct it in the config files. Then most of the week worrying about
why Tomcat wasn't recognizing my servlet context.
Would adding a 'try{} catch() {}' help solve your problem?
I've a bunch of ideas for partial solutions but I'll hold off on
those to see whether there's any agreement that there's a problem
here.
Then, turn those ideas into patches and send them along. No need for
agreement, just an itch to scratch.
I don't want to play the wise guy here, it's just that (at last) the
meaning of voluntary work has entered my stubborn head. As in those old
jokes about screwing a bulb: when there's 100 users complaining about a
problem, there's 10 people talking about how to correct it, and one that
actually does something. The volunteer is the 1 in 111 that screws the
bulb.
For me, Tomcat has worked perfectly (esp. v3.3), and so I cannot justify
my working on it. But, as a consequence, I don't either complain about
the product -- in fact, it's got my highest praises.
Un saludo,
Alex.
RE: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
I sure had my "little" flames with Jon, but that is a very important thing I learned from him. I agree that the problem is there - not enough error info - and I had my share of such problems, but this is open source, so, you can fix it. OTOH, some developers can still learn a bit from this kind of feedback and pay a bit more of attention to providing good debug info. Have fun, Paulo Gaspar -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 10:03 Hi Brad! ... I'm about to answer in Jon's favorite manner (hope you don't mind, Jon): Ok, it seems to be a problem. Why don't you fix it? ... Un saludo, Alex.
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
Mel, Please do not CC me directly as I'm already on the list. I have filed your changes away for when I do my next revision of the site (there are several other people's comments that I want to integrate as well). I hear you and you made good suggestions. Also, I do have to say that those two nits are fairly minor given that the scope of the entire article is quite large. In other words, there is plenty of other valid reasons there to not use JSP and that those two nits are really minor in the grand scope of things. :-) thanks, -jon
Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/4/01 3:55 PM, "Brad Cox" [EMAIL PROTECTED] wrote: Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. Yucky. I'm so happy to see that more and more people are waking up to the fact that JSP is bad. I'm also happy to see you worry about form validation issues. That is a problem that we are currently solving in Turbine right now. It is called "Intake". :-) I'll try to make some time to check that out. I find it funny that you decided to group Turbine and Velocity and Webmacro into this big statement about (Yet another language) yet you didn't even really check it out first. That is bad journalism IMHO. Sigh. Yet another typo. I really thought we'd caught them all. Those are just the spelling mistakes...there are plenty of other typo's in that article. #1. Confused "Turbine" with "add programming language features to HTML". #2. Confused "WebMacro" and thus Velocity with "add programming language features to HTML". If you spend time with the products, you would see that isn't the case and you might actually retract your statements. You've touched a nerve here. This is the amount of time that gets consumed installing web based infrastructures. What does that have to do with any of the above? In fact, if you really take the time looking at Velocity, you will see that we have included complete documentation (written by a professional tech writer), numerous working examples, demo Velocity applications bundled with both versions of Tomcat all ready to go, etc. Yes, Turbine needs more work on the examples and documentation front, but it isn't a released product yet (we plan on a JavaOne release) and will definitely have much improved documentation and examples before we release. We are also putting a huge amount of effort into creating a Turbine EE system that is a bundle of everything you need to get started. It is called the Turbine Developers Kit (TDK). [rant removed] I'd be grateful to hear them when you get a moment. I'd be grateful if you would take the time to investigate our solutions (ie: Velocity and Turbine) before you bash them or decide that they are not worthy. :-) Maybe your next article can be about how much you like Velocity and/or Turbine. :-) -jon
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: So we need to fix it :-) After all that's one of the diferences between the zillion templating systems and jsp - a spec with a wide variety of implementations that improve. I do agree with some of Jon's arguments - the spec is not perfect ( but I don't think HTTP spec is perfect either, or HTML or XSLT or even the servlet spec - and for many of those I could list more serious reasons for not using them and choosing a random alternative :-). Costin I would like to hear what is wrong with Velocity's spec: http://jakarta.apache.org/velocity/vtl-reference-guide.html and http://jakarta.apache.org/velocity/user-guide.html http://jakarta.apache.org/velocity/developer-guide.html :-) -jon
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
on 4/5/01 5:35 AM, "Matthew Dornquast" [EMAIL PROTECTED] wrote: I could be wrong given I don't know the full context, but the code from the article on this page: http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead safe, multiple requests coming in on different threads at the same time would cause init() to be called multiple times. -Matthew Yup. I think it has already been fixed in Tomcat (along with some other problems...ie: the double locked checking as well), but that is the example that is published in Jason's Servlet book that is coming out soon so I wanted to use that because his book will be going out to hundreds of thousands of people... I'm more concerned with illustrating my point in the essay than pointing out bad generation of code because that is something that can be fairly easily fixed. -jon
Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: I love the article title: "Just say no to JSP" Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. I'm so happy to see that more and more people are waking up to the fact that JSP is bad. I'm also happy to see you worry about form validation issues. That is a problem that we are currently solving in Turbine right now. It is called "Intake". :-) I'll try to make some time to check that out. It is sad to me that you: #0. Apache/JServe. Can't spell the product name correctly even though it has been around for 4+ years. :-) Sigh. Yet another typo. I really thought we'd caught them all. #1. Confused "Turbine" with "add programming language features to HTML". #2. Confused "WebMacro" and thus Velocity with "add programming language features to HTML". If you spend time with the products, you would see that isn't the case and you might actually retract your statements. You've touched a nerve here. This is the amount of time that gets consumed installing web based infrastructures. Maybe Turbine is an exception and I certainly hope so. I'll pick on Tomcat here because the wounds are still fresh from spending a whole week on what should be a trivial task; porting a running webapp from a deployment server running Linux 6.2 to the server from hell; a hacked "virtual" implementation of FreeBSD at HostPro.com. I should point out at the outset that this isn't to assign blame but to point out a problem... namely, the complexity that developers must deal with to get a working infrastructure in place. My application uses Apache, JServ, Java, and the servlet engine from Tomcat. Period. No taglibs, no JSP, no XML, nothing. Yet it took a whole week to get even this on the air, even though I've been through the tomcat configuration process dozens of time by now and had working config files to start with. Much of the problem was expecting the user (me) to translate exception backtraces into what should be done to correct the error. The first problem I hit was a NullPointerException while reading request parameters. Why? I've no idea. An unfamilar JRE was preinstalled so guessing, I installed plain ol' JDK1.1.7 and that seemed to fix it. Next problem was various JServ failures, none clearly explained by the errors, and none explaining what what was wrong and how to correct it in the config files. Then most of the week worrying about why Tomcat wasn't recognizing my servlet context. I've a bunch of ideas for partial solutions but I'll hold off on those to see whether there's any agreement that there's a problem here. I have more comments, but no time right now and this probably isn't the right forum anyway... I'd be grateful to hear them when you get a moment. -- --- Brad Cox, Ph.D.; [EMAIL PROTECTED] Phone: 703 361 4751 Cell: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum
