JSP compiled into servlet

Whenver u compile a JSP page it is internally converted into servlet.Where will this servlet be stored and by what name?

<tomcat_home>\work\Catalina\localhost\<Context Name>\org\apache\jsp
You can find below files in above directory of your PC.
<jsp file name>_jsp.java
<jsp file name>_jsp.class
Example:
index_jsp.java
index_jsp.class

Similar Messages

  • Move jsp code into servlet, not work!!

    Hi:
    I am new in servlet and java, I can use jdom to read xml file
    into a jsp file, but whan I move jsp code into servlet, they are not work
    have any ideals?
    Thank!

    Hi:
    my.jsp
    <%@ page contentType="text/html"%>
    <%@ page import="java.io.File,
    java.util.*,
    org.jdom.*,
    org.jdom.input.SAXBuilder,
    org.jdom.output.*" %>
    <%
    String Records = "c:/XMl/Quotes.xml";
    SAXBuilder builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser");
    Document l_doc = builder.build(new File(Records));
    my servlet
    import java.io.*;
    import javax.servlet.*;
    import javax.servlet.http.*;
    import org.jdom.*;
    import org.jdom.input.*;
    import org.jdom.input.SAXBuilder;
    import org.jdom.output.*;
    public class XmlJdom extends HttpServlet
    String Records = "c:/xml/Quotes.xml";
    SAXBuilder builder = null;
    Element Author = null;
    Element Text = null;
    Element Date = null;
    * Initializes the servlet.
    public void init(ServletConfig config) throws ServletException
    super.init(config); //pass ServletConfig to parent
    try
    // JDOM can build JDOM trees from a variety of input sources. One
    // of those input sources is a SAX parser.
    SAXBuilder builder = new SAXBuilder("org.apache.xerces.parsers.SAXParser");
    catch ( org.jdom.JDOMEXception e)
    public void doGet(
    HttpServletRequest request,
    HttpServletResponse response)
         throws IOException, ServletException
         PrintWriter out = null;
         out = response.getWriter();
         try{                
         Document l_doc = builder.build(new File(Records));
    Element root = l_doc.getRootElement();
    //get a list of all recode in my XML document
    String l_pages = root.getChild("quote");
    String Iterator e = l_pages.iterator();
    while ( e.hasNext())
    Element l_quote= (Element) e.next();
         Element l_Author = l_quote.getChild("Date").getChild("Text");
    XMLOutputter l_format = new XMLOutputter();
    String ls_result = l_format.outputString(l_doc);
    out.println(ls_result);
    catch( org.jdom.JDOMException e )
         finally
              if( out != null)
                   out.close();
    Please tell me, what is wrong!!!
    Element root = l_doc.getRootElement();
    /* get a list of all the links in our XML document */
    List l_pages = root.getChildren("quote");
    Iterator Myloop = l_pages.iterator();
    while ( Myloop.hasNext())
    Element l_quote= (Element) Myloop.next();
         Element l_Author = l_quote.getChild("Date").getChild("Text");
    XMLOutputter l_format = new XMLOutputter();
    String ls_result = l_format.outputString(l_doc);
    ls_result = l_format.outputString(l_doc);
    %>
    <html><head><title></title></head>
         <body>
              <pre>
              <%=ls_result%>
              </pre>
         </body>
    </html>

  • Is jsp runs under servlet container ?

    i heard that jsp converted into servlet and compiled at once when it is requested .jsp engine involving this converting process.
    is this file runs in same servlet container or any other jsp container?
    Thanks and regards,

    gunss wrote:
    i heard that jsp converted into servlet and compiled at once when it is requested .jsp engine involving this converting process.Yes. The JSP is parsed and converted into a .java file, which is then compiled into a .class file. It is a servlet, and it runs in the servlet container.
    is this file runs in same servlet container or any other jsp container?Where else would it run?
    %

  • JSP compiler obfuscates generated servlet debug line numbers

              Here's something that's been baffling me for a couple of days now.
              When WebLogic parses a JSP into servlet Java source, and then compiles the Java
              source into a class, it seems to perform a further step to obfuscate debug line
              numbers in the _jspService method. This converts the debug line numbers from Java
              source code line numbers into JSP line numbers.
              At first sight, this may appear to be useful- it means that when an exception
              is thrown then it references a line number in the original JSP rather than one
              in the generated servlet. However, it actually makes life more difficult when
              you consider included JSPs.
              Suppose you have a file loginresult.jsp, which uses @include to include a header.jsp
              and footer.jsp, both of which contain dynamic content. When WebLogic converts
              line numbers, it ignores the JSP that the code came from, so this causes a many-to-one
              mapping of line numbers. When an error occurs, the exception will tell you the
              line number that it came from, but it won't tell you which JSP caused it. The
              many-to-one mapping ensures a loss of information- and no way of retrieving the
              real line numbers.
              This is an even bigger nuisance when trying to debug JSPs- the debugger hops around
              in the generated servlet file without giving any clue as to whereabouts it really
              is in the code.
              My question is: is there any way of switching off this post-processor behaviour?
              One obvious way would be to locate the WebLogic class that does this post-processing,
              stub it out and run WebLogic with this class higher up in the classpath. But that's
              a last resort.
              Secondly, would there be any other impact in turning off this behaviour? Do other
              parts of WebLogic rely on this?
              Thanks in advance,
              Kevin.
              

    Actually, this option turns line-number table replacement on and off, for example,
              with jsp like this:
              test.jsp
              <%
              throw new Exception();
              %>
              and weblogic.xml:
              <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
              Systems, Inc.//DTD Web Application 7.0//EN"
              "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
              <weblogic-web-app>
              <jsp-descriptor>
              <jsp-param>
              <param-name>debug</param-name>
              <param-value>true</param-value>
              </jsp-param>
              </jsp-descriptor>
              </weblogic-web-app>
              the stacktrace looks like this (note line number 2 - this is JSP line number):
              java.lang.Exception
              at jsp_servlet.__test._jspService(test.jsp:2)
              at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
              at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
              at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
              at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
              and with debug option turned off:
              <!DOCTYPE weblogic-web-app PUBLIC "-//BEA
              Systems, Inc.//DTD Web Application 7.0//EN"
              "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
              <weblogic-web-app>
              <jsp-descriptor>
              <jsp-param>
              <param-name>debug</param-name>
              <param-value>false</param-value>
              </jsp-param>
              </jsp-descriptor>
              </weblogic-web-app>
              exception stacktrace looks like this (note that line number now is from generated .java file):
              java.lang.Exception
              at jsp_servlet.__test._jspService(__test.java:87)
              at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
              at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:376)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
              at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5360)
              at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
              at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
              at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
              Kevin Thomas <[email protected]> wrote:
              > But this isn't useful, as you don't know which JSP the line number is referring
              > to! (did it come from the main JSP, or one of the files that it included?)
              > Turning debug off is not an answer- because that will lose other useful information
              > that is useful to the debugger.
              > Kevin.
              > "Dimitri I. Rakitine" <[email protected]> wrote:
              >>Actually, this is useful when you want to debug .jsp's and not generated
              >>..java files. Did you try setting 'debug' jsp-param in the weblogic.xml
              >>to
              >>false? I think it turns class postprocessing on and off.
              >>
              >>Kevin Thomas <[email protected]> wrote:
              >>
              >>> Here's something that's been baffling me for a couple of days now.
              >>
              >>> When WebLogic parses a JSP into servlet Java source, and then compiles
              >>the Java
              >>> source into a class, it seems to perform a further step to obfuscate
              >>debug line
              >>> numbers in the _jspService method. This converts the debug line numbers
              >>from Java
              >>> source code line numbers into JSP line numbers.
              >>
              >>> At first sight, this may appear to be useful- it means that when an
              >>exception
              >>> is thrown then it references a line number in the original JSP rather
              >>than one
              >>> in the generated servlet. However, it actually makes life more difficult
              >>when
              >>> you consider included JSPs.
              >>
              >>> Suppose you have a file loginresult.jsp, which uses @include to include
              >>a header.jsp
              >>> and footer.jsp, both of which contain dynamic content. When WebLogic
              >>converts
              >>> line numbers, it ignores the JSP that the code came from, so this causes
              >>a many-to-one
              >>> mapping of line numbers. When an error occurs, the exception will tell
              >>you the
              >>> line number that it came from, but it won't tell you which JSP caused
              >>it. The
              >>> many-to-one mapping ensures a loss of information- and no way of retrieving
              >>the
              >>> real line numbers.
              >>
              >>> This is an even bigger nuisance when trying to debug JSPs- the debugger
              >>hops around
              >>> in the generated servlet file without giving any clue as to whereabouts
              >>it really
              >>> is in the code.
              >>
              >>> My question is: is there any way of switching off this post-processor
              >>behaviour?
              >>> One obvious way would be to locate the WebLogic class that does this
              >>post-processing,
              >>> stub it out and run WebLogic with this class higher up in the classpath.
              >>But that's
              >>> a last resort.
              >>
              >>> Secondly, would there be any other impact in turning off this behaviour?
              >>Do other
              >>> parts of WebLogic rely on this?
              >>
              >>> Thanks in advance,
              >>
              >>> Kevin.
              >>
              >>--
              >>Dimitri
              >>
              Dimitri
              

  • Why jsp is converted into servlet?

    hi,
    Why the jsp is converted into servlet in the container? reason? why cant is evalute as a jsp file itself? why did not they develope a seperate container for jsp?

    hi :-)
    Why the jsp is converted into servlet in the container? reason? why cant is evalute as a jsp file itself?
    JSP is an extension of servlet technology :-)
    why did not they develope a seperate container for jsp?
    Note: (an excerpt from a book)
    "Inside the JSP container is a special servlet called the page compiler.
    The servlet container is configured to forward to this page compiler all HTTP
    requests with URLs that match the .jsp file extension.
    This page compiler turns a servlet container into a JSP container.
    When a .jsp page is first called, the page compiler parses and compiles
    the .jsp page into a servlet class. If the compilation is successful,
    the jsp servlet class is loaded into memory. On subsequent calls,
    the servlet class for that .jsp page is already in memory; however, it could have been updated.
    Therefore, the page compiler servlet will always
    compare the timestamp of the jsp servlet with the jsp page. If the .jsp page
    is more current, recompilation is necessary. With this process, once
    deployed, JSP pages only go through the time-consuming compilation
    process once"
    For more info you can refer to the packages: javax.servlet.jsp and
    javax.servlet.jsp.tagext
    and also the two servlet packages: javax.servlet and javax.servlet.http
    you might be asking why refer to servlet packages? because JSP needs it :-)
    as i mention earlier, JSP is an extension of servlet technology.
    hope other's will also give answer about your question.
    regards,

  • How to call a function defined in a JSP file into a servlet?

    Hi
    I have defined a JSP file with some functions in it. I am including this JSP file into other JSP files so that these functions can be used. Now is there soe way, that I can include this file in a servlet as well and use the defined functions in the servlet as well.
    Thanks and Regards
    Vikram

    I assume you have a function with OUT arguments because you need to return at least two distinct things from this function? The functions return value and this OUT argument, too. Right? For the sake of argument, let's say that you're trying to return a VARCHAR2 value and a NUMBER value from this function.
    Assuming that you cannot just wrap your existing function with a function that does not have OUT arguments, the first idea that pops to mind is to create an Oracle8 type that looks like:
    CREATE TYPE MYREC AS OBJECT (V VARCHAR2(80), N NUMBER);Then you could rewrite your function to return an instance of this MYREC type instead of having one return value and one OUT parameter.
    Then create a BC4J domain for this Oracle8 type (which will mimic its nested structure), and then you can just select the value straight-away in your view object.
    I just tried this idea with 9.0.2 production and it works.
    The Domain you create will have getV() and getN() accessors on it so you can get at the nested values in the MyRec domain "record" structure.
    The other way would involve building a programmatic view object that sources the data for your VO programmatically. If I think of anything else I'll post something here.

  • UTF-8 encoded JSPs compilation problem

    Hi,
              I'm using Weblogic 9.0 Beta. I have an XML-format UTF-8 encoded JSP (with the proper encoding declarations). I can see that this is compiled into a UTF-8 Java servlet by WebLogic.
              At the compilation to a class file though, the encoding is corrupted. I guess that the Java compiler is assuming a system-encoded (which would be ISO-8859-1) Java file instead of the actual UTF-8 encoding.
              This problem did not occur with WebLogic 8.1.
              I have tried to explicitly tell the Java compiler to treat the source files as UTF-8 in weblogic.xml, i.e.
              <jsp-param>
              <param-name>compileFlags</param-name>
              <param-value>-encoding UTF8</param-value>
              </jsp-param>
              but that had no effect.
              Anyone else noticed this?
              I assume that correct behaviour is for WebLogic to preserve encoding from JSP to servlet to class file, rather than for me to set encoding in weblogic.xml. Is that correct?
              Is there a workaround?
              Thanks for any help you can offer!

    Solved
    It is about Tomcat's character encoding not about the codes..
    For more info:
    [http://wiki.apache.org/tomcat/Tomcat/UTF-8]

  • Jsp compile exception in WL 8.1

              Hi all
              i was trying to deploy the external war(jstl.war from www.manning.com) file in
              my weblogic server .
              I just copied the *.war file into C:\TestDrive\MyDomain\mydomain\application
              directory and restarted the weblogic server.
              i got following error.
              Compilation of 'C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java'
              failed:
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:142:
              'try' without 'catch' or 'finally'
              probably occurred due to an error in /index.jsp line 3:
              <c:import url="header.jsp"/>
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:132:
              'try' without 'catch' or 'finally'
              (No more information available, probably caused by another error)
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:178:
              '}' expected
              (No more information available, probably caused by another error)
              Full compiler error(s):
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:142:
              'try' without 'catch' or 'finally'
              try { // TryCatchFinally begin //[ /index.jsp; Line: 3]
              ^
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:132:
              'try' without 'catch' or 'finally'
              try { // error page try block
              ^
              C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:178:
              '}' expected
              ^
              3 errors
              Thu Sep 25 15:59:58 GMT+05:30 2003
              Same file when i deployed in Tomcat4.1 was working fine i.e. copying the *.war
              into <tomcathome>/webapps directory. I got index page without touching the code!
              Is there any extra settings has to be done for running jsp's from war files in
              WL?
              THanks in advance
              Manjunath
              

    manjunath wrote:
              > further to my previous mail here's the log
              >
              > weblogic.servlet.jsp.CompilationException: Compilation of C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java
              > failed.
              >      at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:446)
              >      at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:220)
              >      at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:172)
              >      at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:504)
              >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:349)
              >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
              >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
              >      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
              >      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              >      at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
              >      at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
              >      at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              >      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > Caused by: java.io.IOException: Compiler failed executable.exec
              >      at weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(CompilerInvoker.java:470)
              >      at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:329)
              >      at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:337)
              >      at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:322)
              >      at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:419)
              >      ... 13 more
              >
              > Here's my weblogic.xml file
              >
              > <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
              > "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
              > <weblogic-web-app>
              > <jsp-descriptor>
              > <jsp-param>
              > <param-name>
              > compileFlags
              > </param-name>
              > <param-value>
              > -g
              > </param-value>
              > </jsp-param>
              >
              >           
              > <jsp-param>
              > <param-name>
              > keepgenerated
              > </param-name>
              > <param-value>
              > true
              > </param-value>
              > </jsp-param>
              >      
              >
              > </jsp-descriptor>
              > </weblogic-web-app>
              >
              > In this URL http://e-docs.bea.com/wls/docs81/jsp/reference.html#57794 there's
              > option to use -webapp for jsp compiler. How to implement same in weblogic.xml
              > <jsp-descriptor> file?
              >
              > Thanks
              >
              > "Manjunath B" <[email protected]> wrote:
              >
              >>Hi all
              >>
              >>i was trying to deploy the external war(jstl.war from www.manning.com)
              >>file in
              >>my weblogic server .
              >>
              >>I just copied the *.war file into C:\TestDrive\MyDomain\mydomain\application
              >>directory and restarted the weblogic server.
              >>
              >>i got following error.
              >>
              >>**********************************************************
              >>Compilation of 'C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java'
              >>failed:
              >>--------------------------------------------------------------------------------
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:142:
              >>'try' without 'catch' or 'finally'
              >>probably occurred due to an error in /index.jsp line 3:
              >><c:import url="header.jsp"/>
              >>
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:132:
              >>'try' without 'catch' or 'finally'
              >>(No more information available, probably caused by another error)
              >>
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:178:
              >>'}' expected
              >>(No more information available, probably caused by another error)
              >>
              >>
              >>--------------------------------------------------------------------------------
              >>Full compiler error(s):
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:142:
              >>'try' without 'catch' or 'finally'
              >> try { // TryCatchFinally begin //[ /index.jsp; Line: 3]
              >> ^
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:132:
              >>'try' without 'catch' or 'finally'
              >> try { // error page try block
              >> ^
              >>C:\TestDrive\MyDomain\mydomain\.\myserver\.wlnotdelete\extract\myserver__appsdir_jstlbook_war_jstlbook\jsp_servlet\__index.java:178:
              >>'}' expected
              >> }
              >> ^
              >>3 errors
              >>
              >>
              >>--------------------------------------------------------------------------------
              >>Thu Sep 25 15:59:58 GMT+05:30 2003
              >>*******************************************************************
              >>
              >>
              >>Same file when i deployed in Tomcat4.1 was working fine i.e. copying
              >>the *.war
              >>into <tomcathome>/webapps directory. I got index page without touching
              >>the code!
              >>
              >>Is there any extra settings has to be done for running jsp's from war
              >>files in
              >>WL?
              >>
              >>THanks in advance
              >>
              >>Manjunath
              >>
              >
              >
              Please contact customer support [email protected] and request a patch for
              CR112789. AT_END tags do not work correctly in 81sp1
              

  • Generating the JSP from the Servlet source file

    Hi,
    Does anyone out there know if there is any utility/class/program which will generate a JSP from the Servlet Source file (.java file) or indeed from the compiled Servlet file (.class file)
    If its possible to decompile a .class file into a .java file, surely it must be possible to convert the .java souce file into the .jsp file that created it.
    any comments would be appreciated
    Richard

    I am the author of the original JSP!
    But I want to run a script on the generated Servlet source file,
    changing its contents, and then generate the JSP that would have created the new Servlet source file.
    but I need to know if theres anything that will reverse engineer a Servlet source into the generating JSP.
    its a kind of of Jeopardy type thing!

  • HELP.....!!!!! Chinese jsp compilation problem.....

    Hi,
    Could someone please help on the above mentioned?
    I'm using JDeveloper 3.2.3 for my program development under Chinese windows platform. I have created a simple JSP page, which contains few static Chinese words and I have included the line
    <%@ page contentType="text/html;charset=UTF-8"%>
    at the top of the page. When I tried to compile it using encoding "UTF8" (under compiler option), the compiler gave me this error:
    C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.jsp
    Error: (0) sun.io.MalformedInputException.
    Btw, when I have removed the line <%@ page contentType="text/html;charset=UTF-8"%> from the page and compile, I've got this error:
    C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.jsp
    Warning: (0) ISO-8859-1 character set may not match project compiler setting.
    C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.java
    Error: (0) malformed input character in C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.java.
    I do appreciate your help on this. Thank you.

    Here's some info one of the JSP Developers sent me:
    1. HELP.....!!!!! Chinese jsp compilation problem.....
    The customer is trying to parse a document generated by
    Windows's notepad. When saved in UTF-8, the byte
    order mark is saved too. We have a know bug that
    JSP parser doesn't recognize Byte Order Mark. The
    bug is : 1915285.
    2. CHINESE CHARACTER ON JSP
    . SQLPLUS depends on NLS_LANG setting. If you
    check the windows registry, the default of NLS_LANG
    depends on the OS. The user environment is Traditional
    Chinese, so does NLS_LANG. If we set NLS_LANG
    to .UTF8, SQLPLUS dumps the data in UTF8, however,
    the command prompt will have problem displaying them.
    . For JSP, as mentioned in a previous mail:
    <%@ page contentType="text/html;charset=UTF-8" %> for all languages
    <%@ page contentType="text/html;charset=GB2312" %> for simplified Chinese
    <%@ page contentType="text/html;charset=Big5" %> for traditional Chinese
    . When you enter Chinese characters on a browser,
    the data is automatically converted to page encoding
    (UTF-8 in your case) before sent back to the server.
    But your receiving servlet/JSP needs to have request
    encoding set correctly.
        I'm not sure about the JDeveloper environment,
    but here is a simple JSP you may try to verify your
    OC4J environment:
    a.    To set up the schema:
    connect scott/tiger
    create table tab01(col varchar2(100));
    b. Edit the connect string in nls.jsp
    c. Run the nls.jsp in oc4j instance.
    <!-- nls.jsp -->
    <%@ page contentType="text/html; charset=UTF-8" %>
    <%@ page import="oracle.jdbc.*,java.sql.*,java.io.*"%>
    <HTML>
    <HEAD>
    <TITLE>Hello</TITLE></HEAD>
    <BODY>
    <%
    request.setCharacterEncoding("UTF-8");
    String sampledata="\u7D20";
    String paramValue = request.getParameter("myparam");
    String connStr = "jdbc:oracle:thin:@dlsun478:5521:j2ee01";
    String user = "scott";
    String passwd = "tiger";
    DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
    Connection conn = DriverManager.getConnection(connStr, user, passwd);
    if (paramValue == null || paramValue.length() == 0) { %>
       <FORM METHOD="GET">
       Please input your name: <INPUT TYPE="TEXT" NAME="myparam"
    value="<%=sampledata%>" size=20>
    <BR>
       <INPUT TYPE="SUBMIT" value="Insert Data">
       </FORM>
    <%
      selectData(conn, out);
    else
    %>
       <H1> Insert Data: <%= paramValue %> </H1>
       <br/>
    <%
      insertData(conn, paramValue);
    %>
    <a href="nls.jsp">back</a>
    <%
    %>
    </BODY>
    </HTML>
    <%!
      public void insertData(Connection aConn, String myval)
        try {
          PreparedStatement stmt = aConn.prepareStatement("insert into tab01
    values(?)");
          stmt.setString(1, myval);
          stmt.executeUpdate();
          aConn.close();
        catch (SQLException e) {
          e.printStackTrace();
      public void selectData (Connection aConn, JspWriter out)
        try {
          Statement stmt = aConn.createStatement( );
          ResultSet r = stmt.executeQuery("SELECT col FROM tab01");
          out.println("<H1>List of Data:</H1>");
          while (r.next()) {
            out.println(r.getString(1)+"<br/>");
          aConn.close();
        catch (SQLException e) {
          e.printStackTrace();
        catch (IOException e) {
          e.printStackTrace();
    %>

  • Why we should use JSP instead of Servlet ?

    I want to know what are the advantages to use JSP over Servlet.

    hi
    Servlets are server exctension ( like CGI ) separate executable
    modules to serve any request efficiently.
    Servlets are pure java classes, u can use them the write an html code to browser.
    u have to compile the servlet before u use it.
    JSP page, is a text-base document , u can type html inside it , and u can use java as scripting language, so it is more easy to use jsp rather than servlet as each jsp page is translated into a servlet by JSP engine.
    Hope this will help
    Good luck
    Mohammed

  • Please help me resolve this JSP compilation error

    Hi,
    We have deployed our web app in Sun one web server 7.0 running on Sun os, and with JRE 5.0.
    Until recently, every thing was running fine, but since a few days, I am unable to get a JSP file compiled.
    This file, has a <%@include file= .. > to another file, and both these used to work fine earlier.
    This is the error message I am getting:
    <!-- org.apache.jasper.JasperException: PWC6033: Unable to compile class for JSP
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:464)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:358)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:917)
    at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:792)
    at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:472)
    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:353)
    at com.bt.bmsnet.shared.BMSServletBase.forward(BMSServletBase.java:126)
    at com.bt.gma.web.AccountServlet.actionUpdateAccount(AccountServlet.java:2704)
    at com.bt.gma.web.AccountServlet.doGet(AccountServlet.java:5049)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:796)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:917)
    at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
    at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:187)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
    at com.sun.webserver.connector.nsapi.NSAPIProcessor.service(NSAPIProcessor.java:160)
    Caused by: java.io.IOException: tmpFile.renameTo(classFile) failed
    at org.apache.jasper.compiler.SmapUtil$SDEInstaller.install(SmapUtil.java:208)
    at org.apache.jasper.compiler.SmapUtil.installSmap(SmapUtil.java:131)
    at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:336)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:369)
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:595)
    ... 23 more
    -->
    The line "Caused by: java.io.IOException: tmpFile.renameTo(classFile) failed" suggests that the JSP file isn't getting compiled into the corresponding servlet.
    Can some one please help?

    Yes I have done that. Simple JSP pages are compiling well. But I have about 5 jsps which call some partial jsp using
    <%@ include file="somefile.jsp" %>
    And all these files are showing this error.
    I have a feeling that this is probably due to some kind of restriction on file sizes of compiled jsps in the server. Is there any such restriction?

  • Why do I get the JSP compilation error?

    Why do I get the JSP compilation error?
              Envionment:
              AIX,WLS 5.1 sp10,.........
              Thu Jun 07 11:54:41 CDT 2001:<I> <ServletContext-dcms> Generated java
              file: /usr/local/weblogic/test-weblogic/weblogic/myserver/dcms
              web/app/tmp_war/jsp_servlet/_report/_walmart_95_prod_95_proof_95_report.java
              Thu Jun 07 11:54:42 CDT 2001:<E> <ServletContext-dcms> Compilation of
              /usr/local/weblogic/test-weblogic/weblogic/myserver/dcms_web/a
              pp/_tmp_war/jsp_servlet/_report/_walmart_95_prod_95_proof_95_report.java
              failed: Exception in thread "main" java.lang.NoClassDefFoun
              dError: sun/tools/javac/Main
              java.io.IOException: Compiler failed
              executable.exec([Ljava.lang.String;[javac, -classpath,
              /usr/java_dev2/jre/sh/../lib/rt.jar:/usr
              /java_dev2/jre/sh/../lib/i18n.jar:/usr/java_dev2/jre/sh/../classes:./classes/boot:./eval/cloudscape/lib/cloudscape.jar:./anderson_co
              mmon/3rd_party_jars/jt400.jar:/usr/lpp/db2_07_01/java/db2java.zip::./lib/weblogic510sp8boot.jar:./license:./classes:./lib/weblogicau
              x.jar:./myserver/serverclasses:./anderson_common/3rd_party_jars/jt400.jar:/usr/lpp/db2_07_01/java/db2java.zip::./classes/dcms/com.ib
              m.mq.iiop.jar:./classes/dcms/com.ibm.mq.jar:./classes/dcms/com.ibm.mqbind.jar:./classes/dcms/com.ibm.mqjms.jar:./classes/dcms/com_au
              th.jar:./classes/dcms/com_auth_server.jar:./classes/dcms/com_io.jar:./classes/dcms/com_jms.jar:./classes/dcms/com_jndi.jar:./classes
              /dcms/com_system.jar:./classes/dcms/com_system_server.jar:./classes/dcms/com_util.jar:./classes/dcms/dcms_common.jar:./classes/dcms/
              dcms_common_server.jar:./classes/dcms/dcms_dl_render_server.jar:./classes/dcms/dcms_finalresting_server.jar:./classes/dcms/dcms_fulf
              illment.jar:./classes/dcms/dcms_fulfillment_server.jar:./classes/dcms/dcms_fulfillment_walmart_server.jar:./classes/dcms/dcms_lookup
              _server.jar:./classes/dcms/dcms_media_server.jar:./classes/dcms/dcms_order.jar:./classes/dcms/dcms_order_server.jar:./classes/dcms/d
              cms_order_session.jar:./classes/dcms/dcms_product.jar:./classes/dcms/dcms_product_server.jar:./classes/dcms/dcms_render_client.jar:.
              /classes/dcms/dcms_render_server.jar:./classes/dcms/dcms_talent_server.jar:./classes/dcms/dcms_talent.jar:./classes/dcms/dcms_walmar
              t.jar:./classes/dcms/dcms_walmart_server.jar:./classes/dcms/dcms_jms.jar:./classes/dcms/xreport_pro.jar:./classes/dcms/xtools.jar:./
              classes/dcms/jms.jar:./classes/dcms/dcms_sql.jar:./classes/dcms/dcms_product_sql.jar::/usr/local/weblogic/test-weblogic/weblogic/mys
              erver/tmp_deployments/ejbjar-4971.jar:/usr/local/weblogic/test-weblogic/weblogic/lib/persistence/WebLogic_RDBMS.jar:/usr/local/weblo
              gic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4970.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployme
              nts/ejbjar-4969.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4968.jar:/usr/local/weblogic/test-web
              logic/weblogic/myserver/tmp_deployments/ejbjar-4967.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4
              966.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4965.jar:/usr/local/weblogic/test-weblogic/weblog
              ic/myserver/tmp_deployments/ejbjar-4964.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4963.jar:/usr
              /local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4962.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/
              tmp_deployments/ejbjar-4961.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4960.jar:/usr/local/weblo
              gic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4959.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployme
              nts/ejbjar-4958.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4957.jar:/usr/local/weblogic/test-web
              logic/weblogic/myserver/tmp_deployments/ejbjar-4956.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4
              955.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4954.jar:/usr/local/weblogic/test-weblogic/weblog
              ic/myserver/tmp_deployments/ejbjar-4953.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4952.jar:/usr
              /local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4951.jar:/usr/local/weblogic/test-weblogic/weblogic/./myserve
              r/dcms_web/app/WEB-INF/classes:/usr/local/test-weblogic/weblogic/myserver/dcms_web/app/WEB-INF/classes:/usr/local/weblogic/test-webl
              ogic/weblogic/./myserver/dcms_web/app/_tmp_war:/usr/local/weblogic/test-weblogic/weblogic/myserver/dcms_web/app/_tmp_war,
              -d, /usr/l
              ocal/weblogic/test-weblogic/weblogic/myserver/dcms_web/app/_tmp_war,
              /usr/local/weblogic/test-weblogic/weblogic/myserver/dcms_web/ap
              p/_tmp_war/jsp_servlet/_report/_walmart_95_prod_95_proof_95_report.java])
              at
              weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(CompilerInvoker.java:396)
              at
              weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:202)
              at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:284)
              at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:174)
              at
              weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:164)
              at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:99)
              at
              weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java(Compiled
              Code))
              at com.web.CommonWebUtils.forward(CommonWebUtils.java(Compiled
              Code))
              at com.web.PageNavServlet.service(PageNavServlet.java:76)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
              at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
              at
              weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:742)
              at
              weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:686)
              at
              weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:247)
              at
              weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:361)
              at
              weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:261)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              ----------------------Caught exception while forwarding to page
              /report/walmart_prod_proof_report.jsp------------------------
              ----------------------Exception java.io.IOException: Compiler failed
              executable.exec([Ljava.lang.String;[javac, -classpath, /usr/jav
              a_dev2/jre/sh/../lib/rt.jar:/usr/java_dev2/jre/sh/../lib/i18n.jar:/usr/java_dev2/jre/sh/../classes:./classes/boot:./eval/cloudscape/
              lib/cloudscape.jar:./anderson_common/3rd_party_jars/jt400.jar:/usr/lpp/db2_07_01/java/db2java.zip::./lib/weblogic510sp8boot.jar:./li
              cense:./classes:./lib/weblogicaux.jar:./myserver/serverclasses:./anderson_common/3rd_party_jars/jt400.jar:/usr/lpp/db2_07_01/java/db
              2java.zip::./classes/dcms/com.ibm.mq.iiop.jar:./classes/dcms/com.ibm.mq.jar:./classes/dcms/com.ibm.mqbind.jar:./classes/dcms/com.ibm
              .mqjms.jar:./classes/dcms/com_auth.jar:./classes/dcms/com_auth_server.jar:./classes/dcms/com_io.jar:./classes/dcms/com_jms.jar:./cla
              sses/dcms/com_jndi.jar:./classes/dcms/com_system.jar:./classes/dcms/com_system_server.jar:./classes/dcms/com_util.jar:./classes/dcms
              /dcms_common.jar:./classes/dcms/dcms_common_server.jar:./classes/dcms/dcms_dl_render_server.jar:./classes/dcms/dcms_finalresting_ser
              ver.jar:./classes/dcms/dcms_fulfillment.jar:./classes/dcms/dcms_fulfillment_server.jar:./classes/dcms/dcms_fulfillment_walmart_serve
              r.jar:./classes/dcms/dcms_lookup_server.jar:./classes/dcms/dcms_med
              rder_server.jar:./classes/dcms/dcms_order_session.jar:./classes/dcm
              es/dcms/dcms_render_client.jar:./classes/dcms/dcms_render_server.jar:./classes/dcms/dcms_talent_server.jar:./classes/dcms/dcms_talen
              t.jar:./classes/dcms/dcms_walmart.jar:./classes/dcms/dcms_walmart_server.jar:./classes/dcms/dcms_jms.jar:./classes/dcms/xreport_pro.
              jar:./classes/dcms/xtools.jar:./classes/dcms/jms.jar:./classes/dcms/dcms_sql.jar:./classes/dcms/dcms_product_sql.jar::/usr/local/web
              logic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4971.jar:/usr/local/weblogic/test-weblogic/weblogic/lib/persistence/Web
              Logic_RDBMS.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4970.jar:/usr/local/weblogic/test-weblogi
              c/weblogic/myserver/tmp_deployments/ejbjar-4969.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4968.
              jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4967.jar:/usr/local/weblogic/test-weblogic/weblogic/m
              yserver/tmp_deployments/ejbjar-4966.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4965.jar:/usr/loc
              al/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4964.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_
              deployments/ejbjar-4963.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4962.jar:/usr/local/weblogic/
              test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4961.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/
              ejbjar-4960.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4959.jar:/usr/local/weblogic/test-weblogi
              c/weblogic/myserver/tmp_deployments/ejbjar-4958.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4957.
              jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4956.jar:/usr/local/weblogic/test-weblogic/weblogic/m
              yserver/tmp_deployments/ejbjar-4955.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4954.jar:/usr/loc
              al/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4953.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_
              deployments/ejbjar-4952.jar:/usr/local/weblogic/test-weblogic/weblogic/myserver/tmp_deployments/ejbjar-4951.jar:/usr/local/weblogic/
              test-weblogic/weblogic/./myserver/dcms_web/app/WEB-INF/classes:/usr/local/test-weblogic/weblogic/myserver/dcms_web/app/WEB-INF/class
              es:/usr/local/weblogic/test-weblogic/weblogic/./myserver/dcms_web/app/_tmp_war:/usr/local/weblogic/test-weblogic/weblogic/myserver/d
              cms_web/app/_tmp_war, -d,
              /usr/local/weblogic/test-weblogic/weblogic/myserver/dcms_web/app/_tmp_war,
              /usr/local/weblogic/test-weblog
              ic/weblogic/myserver/dcms_web/app/_tmp_war/jsp_servlet/_report/_walmart_95_prod_95_proof_95_report.java])------------------------
              

    Hi, im getting the same thing,
    Been tryin to download it for days but keeps saying "Invalid signature"
    I even went into ADD REMOVE PROGRAMS hit Apple software update and change and then repair but this did not work.
    Help much appreciated.  Thanks

  • JSP Compiler and ClassCastException

     

    Have been using JDK1.2.2 from sun since day one and I've been seeing
              ClassCastException since day 1 too.
              Don't think it had anything to do with the compiler.
              "Jun Ying" <[email protected]> wrote in message
              news:[email protected]...
              > I noticed something that might be causing the ClassCastException and has
              not
              > been mentioned: the compiler that is used for jspc. I remember seeing a
              few
              > people mentioning extra classes in the workDir (ie, the bean class that is
              > being used). This is caused by using a smart compiler such as jikes or
              sj.
              > While those compilers will get you more speed for newly modified jsp's,
              they
              > resolve dependencies and recompile all the referenced classes. The result
              > is that the bean class gets recompiled and put into workDir. So no matter
              > where you put the workDir, you end up getting a new copy of the bean class
              > file, which is reloaded by the classloader that loads the newly compiled
              > JSP. That copy of the class file is considered "different" from the one
              > from the normal system classpath or the weblogic.class.path. Thus the
              > ClassCastException. So if you see java classes other than the jsp's in
              the
              > workDir, make sure you are using javac from the sun jdk. So to answer
              > Anish's question, WebLogic is not sticking a copy of the bean class.
              > Rather, it's the java compiler that you are using.
              >
              > Jun Ying
              > Meritsoft, Inc
              >
              >
              > "Michael Boudreau" <[email protected]> wrote in message
              > news:[email protected]...
              > > Hello,
              > >
              > > Well we ran into the same problem here at my company, and we have been
              > > pulling our hair out. I was reading through the jsp 1.1 spec, and
              > > thought I might try using the <jsp:useBean ...> tag instead of the <%@
              > > page import ...> tag. After careful inspection of the resulting .java
              > > file, I found that the <jsp:useBean ...> tag does not put insert any
              > > import statements, but simply declares the bean with the fully
              > > qualified package name. I am sure that this is not new news to anyone;
              > > however, the class cast exception went away (knock on wood, cross
              > > fingers, whatever).
              > >
              > > Basically, my statement looked like this:
              > > <jsp:useBean id="beanname" type="com.company.Class" scope="session" />
              > >
              > > My question is: is there something that I am missing or have not
              > > thought of? Because so far, this "seems" to be working, but I have
              > > been reading posts that say this does not work.
              > >
              > > Oh, one last quick note to BEA. While I was looking at the
              > > generated .java file from the jsp file, I found that weblogic's jspc is
              > > still generating getValue and setValue methods for HttpSession....
              > > which has been deprecated as of the servlet 2.2 spec.
              > >
              > > Michael
              > >
              > >
              > >
              > >
              > > Anish Parvataneni wrote:
              > >
              > > > Hi,
              > > >
              > > > I have a JSP which uses two different classes. Whenever, I change the
              > > > JSP and save it to recompile, there is a ClassCastException. ( I store
              > > > them in the session and load them) . Thats common ! The solution to
              this
              > > > as per documentation is to get rid of the classes in the workingDir of
              > > > JSP. However, I can find ONLY ONE of the classes in the workingDir. I
              > > > delete that class and the JSP works. I change the JSP , problem
              recurrs.
              > > >
              > > > 1. Why does weblogic stick a copy of the class in the workingDir,
              > > > everytime the JSP compiles, although it is available in the weblogic
              > > > classpath ?
              > > > 2. Why is it happening to only one of the classes I use in the JSP ?
              > > > 3. How can I make sure that this class is not available in the
              > > > workingDir, other than deleting it EVERYTIME.
              > > >
              > > > Thanks
              > > > Anish
              > >
              >
              >
              

  • JSP compile for WARs...

    Hi
    If I wanted to precompile my JSPs and package them into a WAR where would I put them???
    Under WEB-INF/generated/jsp???? Will this work regardless of the app server vendor?
    I tried to look through the JSP spec to find some info on this but couldn't find any (or I may have missed it)
    Is precompiling JSPs and packaging them into a WAR considered a good practice?
    Thanks
    Z

    Well my reasoning was that /WEB-INF/classes is packaged.....and when JSPs are compiled they are compiled into a servlet (if I am not mistaken) which is just another Java class....So it should be vendor neutral...
    On Sun's App Server you can choose precompile at deployment time, but I was wondering if there is a more direct approach...
    I don't think precomilation works like that. Imagine
    compiling jsps for tomcat, and trying to run them in
    websphere.
    As far as I know precompilation is done by calling the
    jsp with a request parameter called
    jsp_precompile and a value of true.

Maybe you are looking for