This is driving me NUTS!!!!
Could someone please explain to me how I must go about accessing the
application object in order to get an application variable in my servlet.
In a JSP I just write:
application.getInitParameter("gUri")
....so far I have gotten the following frigured out (I think) ... but still
no dice!
HELP!!!!!
Thx.
Neal
____________________________________________________________________________
_________
import java.io.*;
import java.text.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
public class myServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws IOException, ServletException {
//Define initial objects
PrintWriter out = response.getWriter();
JspFactory factory = JspFactory.getDefaultFactory();
PageContext pageContext =
factory.getPageContext(this,request,response,null,
false,JspWriter.DEFAULT_BUFFER,true);
//Get JSP implicits, application and session.
ServletContext application = pageContext.getServletContext();
HttpSession session = pageContext.getSession();
//Output - test by writing an application variable.
response.setContentType("text/html");
out.println(application.getInitParameter("gUri"));
}
}
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Craig R. McClanahan
Sent: Saturday, December 30, 2000 9:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [JSP-INTEREST] Servlets v. JSP
"Duffey, Kevin" wrote:
> Despite the fact that the spec says JSP must extend JSPServlet and all
that,
> I am wondering why its not allowed for an app server to do its own thing
> with JSP pages.
They are.
The spec says that an app server can generate a class that extends whatever
base
class it wants to, as long as the resulting servlet implements the
javax.servlet.jsp.JspPage *interface* (not extends the JSPServlet *base
class*).
Most JSP page compilers provide a base class that is unique to that
container,
optimized to make your compiled classes as small as possible (shared code
appears
once in the superclass) and as fast as possible (optimized for the internal
organization of that container).
> For example, I could map *.jsp to my own servlet, which
> would then parse the JSP page, and convert it directly to a servlet..one
> that does not extend JSPServlet or whatever it is. Why is it forced to
> extend JSPServlet?
As above, it is not forced. In fact, you as a page developer have the right
to
tell the JSP compiler to use your own base class, instead of its own, if you
want
to:
<%@ page ... extends="com.mycompany.MyJspBaseClass" ... %>
However, you are explicitly warned that this is likely to make performance
*worse*,
because the page compiler has to give up all the optimizations built in to
the base
class it knows about, and write extra code in the generated servlet to make
sure
your page obeys all of the rules of the spec.
> Seems to me to make it as fast as possible, it would be
> better to just directly convert the JSP page into a single servlet that
> extends nothing (if possible), and make it as lean and fast as possible. I
> don't know if there would be significant improvement in overall site speed
> because of this.
>
By this argument, we should never ever use subclasses, right? :-). I guess
we all
need to go back to C programming -- this "object oriented" stuff wasn't all
it was
cracked up to be :-) :-).
Seriously, whether you use subclasses or not versus implementing the same
code in
every servlet has essentially no impact on performance (other than the fact
that it
costs you more memory because of the code duplication). And, as we all
know, if
the code is only in one place (the superclass), it only needs to be changed
once
when bugs are fixed or new features are added.
The JSP spec gives container vendors quite a lot of latitude to
differentiate
themselves on the generated code quality (and thererfore performance) of
their JSP
implementations -- with you having a guarantee that your page will function
identically on any of them, as long as *you* obey all the spec rules. This
is the
same kind of freedom you have to choose which JVM to run on. For example,
try the
same application on a JDK 1.1 JVM with the JIT turned off, versus a 1.3 JVM
with
HotSpot -- for many interesting classes of applications (including pretty
much all
web apps that are not I/O bound), the performance difference is dramatic.
And that
difference is totally due to changes in the underlying container -- not in
your
code.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
