RE: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

2001-04-08 Thread Carlos Gaston Alvarez

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

2001-04-06 Thread Paulo Gaspar

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

2001-04-06 Thread Paulo Gaspar

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

2001-04-05 Thread Matthew Dornquast

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]

2001-04-05 Thread Mel Martinez


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

2001-04-05 Thread cmanolache

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]

2001-04-05 Thread Mel Martinez


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

2001-04-05 Thread Mel Martinez


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

2001-04-05 Thread Mark T. Harris

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

2001-04-04 Thread Nick Bauman

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]

2001-04-04 Thread Earl . Stutes

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