RE: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> With my team, I try to stress that JSPs can (and > actually should) be used to implement both View and > Control aspects of MVC and to address this we have > adopted (hopefully) strong standards for how we do JSP > development. There is more to it, but basically we > conceptually separate JSPs into four basic roles: > presentation control, presentation content, request > filtering and pure business. We then enforce naming > conventions and required strategies to development of > JSPs in these roles. I don't claim this is ideal, but > it seems to work very well. > I use jsp only to show data (when possible). I do the control at a servlet. Chau, Gaston
RE: "Just say no to JSP" Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 02:00 > > ... > > My only complaints would be not > enough debug tools around to be able to single step through new code > when you are having problems, > > ... JBuilder 4 works just fine for me. And it works on Windows, Linux, Solaris and other Java platforms. Have fun, Paulo Gaspar
RE: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 20:57 > > ... > > Nothing wrong - yet another fine language, and a very nice > implementation. > And nothing good either - or I coulnd't find anything revolutionary > compared with other programming languages or other fine template-like > systems. Not revolucionary at all. The Velocity team publicly recognizes the inspiration from WebMacro. But the implementation makes a difference. I find Velocity much easier to control and mold into my own needs. (Clearer source code sure helps there.) And I am not saying it is perfect. > Arguing what is the best programming language or if interpreted is better > than compiled is mostly a waste of time. Some people will prefer to learn > VTL, other will prefer to use Java, other will like the XML-like syntax. Sure. And compiled is still an open option for Velocity. > I think code generation is a good thing, ... Sure, some template use problems could be easier to debug if there is some intermediate source code and a good debugger. > ... and I prefer using Jsp with Java > for quick prototypes and taglibs when possible. In my case, using JSP + taglibs in JServ (I still do not have a Tomcat production server here) is more trouble than using Velocity. On the other hand, I have a lot of exports to HTML - generation of static HTML from data in a database - and Velocity gives me a big help on that, while JSPs And then, I would like to be able export most of my site's dynamically generated pages to static HTML. Many pages don't change often and it is more efficient to develop dynamically and export to static HTML for production. > Costin Have fun, Paulo
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
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
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Jon Stevens <[EMAIL PROTECTED]> wrote: > Mel, > > Please do not CC me directly as I'm already on the > list. Sorry - artifact of how I started the reply (from browsing the essay). Oops. > 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. :-) > Oh yes, I hope I made it clear that I don't think my two little nits in any way invalidate the larger points. I am simply offering them as constructive ways to improve the argument. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
On Thu, 5 Apr 2001, Mel Martinez wrote: > The above paragraph describes a 'fundamental issue' > that has absolutely nothing to do with the Java Server > Pages specification and, rather, entirely to do with a > particular implementation of the specification. As And most of the other arguments are in the same category - bad implementation of the spec. 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
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman <[EMAIL PROTECTED]> wrote: > Read Jon's article about the problems of JSP. > > http://jakarta.apache.org/velocity/ymtd/ymtd.html > > I read it and it made me rethink a lot of > assumptions I had made about JSP. > Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman <[EMAIL PROTECTED]> wrote: > Read Jon's article about the problems of JSP. > > http://jakarta.apache.org/velocity/ymtd/ymtd.html > > I read it and it made me rethink a lot of > assumptions I had made about JSP. > Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: "Just say no to JSP" Re: [Fwd: Tomcat may reveal script source code by URL trickery]
> I do have all the latest jar files from SUNW, and jakarta-apache. So I > don't know what the problems could be. My only complaints would be not > enough debug tools around to be able to single step through new code > when you are having problems, but I consider that minor at this point, > given where the tomcat development cycle is. I've investigated a LOT of reported Tomcat "bugs" where I work that turned out to be garden-variety bugs in the application (apps not dealing correctly with bad data, apps exiting the JVM because something unexpected happened, etc.). The only issue we've found that didn't appear to be an application bug was one where CPU usage trended to 100% over the span of an hour or so. This was on Tomcat 3.2.1/Solaris ?/JDK 1.2.?. The problem vanished when we switched the environment to JDK 1.3. Given that, we never did take the time to figure out the exact problem. Anyhow, the jdb debugger that is included with jdk 1.3 works pretty well for debugging servlet/JSP code when nothing else is available. The command interface takes a few minutes to understand, but it does get the job done. And of course, to debug JSP code, you really have to go after the generated servlet. It's not pretty, but it does work. During development, a lot of people around here use JBuilder to develop/debug JSP and servlet code. It works well for us.
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. > An alternative view! > > On 4 Apr, Brad Cox wrote: >> At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: >>>I love the article title: >>>"Just say no to JSP" > I am really sorry to see folks coming on this list, and also publishing > to the general web articles deriding JSP and tomcat in particular. I > have apache-1.3.19 with tomcat-3.2.2b running behind it just fine using > mod_jk. The application running is an apache soap server This is on a > redhat 6.2 box. I also have tomcat-4.0 running on port 7070 at the same > time where I am doing development on a secure email application. I have > moved my email app back and forth between TC3.2 and TC4.0 with no > problems. I just drop the war file in the webapps directory and tomcat > does the rest. > > I do have all the latest jar files from SUNW, and jakarta-apache. So I > don't know what the problems could be. My only complaints would be not > enough debug tools around to be able to single step through new code > when you are having problems, but I consider that minor at this point, > given where the tomcat development cycle is. > > I think the tomcat developers for all their good work. > > =eas= > -- > . > | > | > | > | - > | > | * +---+ > | | I'd Rather Be Sailing A Laser | > | -- +---+ > | 83345 > | > | --- > | > |[EMAIL PROTECTED] > |-O--- > |/w-| > ..|=| > I| | > ~~~ -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: "Just say no to JSP" Re: [Fwd: Tomcat may reveal script source code by URL trickery]
An alternative view! On 4 Apr, Brad Cox wrote: > At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: >>I love the article title: >>"Just say no to JSP" I am really sorry to see folks coming on this list, and also publishing to the general web articles deriding JSP and tomcat in particular. I have apache-1.3.19 with tomcat-3.2.2b running behind it just fine using mod_jk. The application running is an apache soap server This is on a redhat 6.2 box. I also have tomcat-4.0 running on port 7070 at the same time where I am doing development on a secure email application. I have moved my email app back and forth between TC3.2 and TC4.0 with no problems. I just drop the war file in the webapps directory and tomcat does the rest. I do have all the latest jar files from SUNW, and jakarta-apache. So I don't know what the problems could be. My only complaints would be not enough debug tools around to be able to single step through new code when you are having problems, but I consider that minor at this point, given where the tomcat development cycle is. I think the tomcat developers for all their good work. =eas= -- . |\ | \ | \ | -\ |\ | * \ +---+ | \| I'd Rather Be Sailing A Laser | | --\ +---+ | 83345 \ | \ | ---\ | \ |\[EMAIL PROTECTED] |-O---\ |/w\-| ..|=| \ I| | ~~~
