|
-----Original Message-----
From: Stone, Brad V (TC) [mailto:bvstone@taylorcorp.com]
Sent: Wednesday, December 20, 2000 8:33 AM
To: 'JAVA400-L@midrange.com'
Subject: RE: Making sure...This is assuming that someone found a way into the IFS where your HTML and JSPs are stored. Who says they couldn't upload a JSP file then try and execute it? That's where I'm going with that.-----Original Message-----
From: DUCRET Gilles (GVA) [mailto:Gilles.DUCRET@lloydsbank.ch]
Sent: Wednesday, December 20, 2000 8:27 AM
To: 'JAVA400-L@midrange.com'
Subject: RE: Making sure...Remark:
One problem with JSP is that they are difficult to maintain. The best is certainly
not to write logic into a jsp file, but to delegate this logic (mostly display logic)
to a bean that is used by the jsp. Therefore, the only code you add to the jsp is calls
to that bean.If you read the sun blue print papers you'll find some documentation about this: like presentation
beans.About security: a jsp is compiled on the server, and the client only sees the generated html
file. I can't see how you could upload a jsp? You don't upload anything, all the code runs on
the server.-----Original Message-----
From: Stone, Brad V (TC) [mailto:bvstone@taylorcorp.com]
Sent: mercredi, 20. décembre 2000 14:51
To: 'JAVA400-L@midrange.com'
Subject: RE: Making sure...
I guess I shouldn't be using IBM's examples then. I'm finding a lot of
programming flaws in them, like it was written for programmers who have only
done RPGII.Why do JSPs scare me? WEll, we've been through this before on another list,
but it seems to me that it is easier to upload a jsp file that could do harm
(same as a net.data macro, ASP, or anything interpreted) than it would be to
install a compiled CGI object (RPG, COBOL, etc).I must admit, I'm working on the servlet example from IBM that reads from a
browser. I must have removed half of the code already. Nasty programming.
Lots of unneeded "ifs" and "hold variables" to check contions. yuck.I haven't even touched on DB access yet. Im sure that will be the defining
moment because it can't be easier than eRPG. :)Brad
> -----Original Message-----
> From: Joe Teff [mailto:JoeTeff@earthlink.net]
> Sent: Tuesday, December 19, 2000 9:57 PM
> To: JAVA400-L@midrange.com
> Subject: RE: Making sure...
>
>
> >JSPs scare me. Seems there could be a security risk, but I
> won't know
> until
> >I play more.
>
> Why? JSPs actually get compiled into a servlet at load time, so they
> function
> exactly the same as a servlet. What is does is allow you to
> separate the
> static HTML from the dynamic code. Much like Net.Data. In
> eRPG I store the
> static HTML in files and then read it into the CGI program.
> Really the same
> result except with JSP there are design tools emerging
> (WebSphere Studio
> and Ultradev to name a couple) that allow you to design your JSP pages
> WYSIWYG
> with placeholders for the Java (JSP tags).
>
> >Servlets. LEt's just say that at this piont comparing to
> e-RPG to servlets
> >is like comparing flying a paper airplane to a 747 as far as
> complexity to
> >do something simple like read data from a web page. But
> maybe one day
> that
> >will change.
>
> I think they are very similar in many regards. Getting environmental
> variables
> is a method call rather than a subprocedure call (assuming
> you encapsulated
> the C APIs in a service program). You can simulate most of
> the request and
> response methods with subprocedures if you want. Doing things
> with session
> is nicer. They do scale better because of spawning threads
> for each request.
> Overall, I see many more similarities than differences. One
> advantage is
> standardization. Everyone uses the same objects and methods
> where as in RPG
> is varies depending on how the subprocedures and service
> programs are set
> up.
> The large class libraries available from Sun and IBM provide
> for a lot of
> functionality right out of the box.
>
> >Now I challenge all of you to try out e-RPG. :)
>
> I have. In fact I did that based on your MC articles before
> your book was
> published.
>
> Joe
>
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
>
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---
**********************************************************************
This E-mail and any files transmitted with it are confidential
and intended for the exclusive use of the addressee(s) only.
You should not disclose its contents to any other person.
If you are not the intended recipient please notify the sender
immediately.
**********************************************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
