Can we precompile JSPs to avoid Weblogic Recompile JSPs

We'll prevent Weblogic 10.3 to Recompile JSPs when deployment and running. So we precompile JSPs when build by weblogic.jspc and added staments below in weblogic.xml, but we failed, weblogic will recompile JSPs as before. Anybody can help me?
<jsp-param>
<param-name>precompile</param-name>
<param-value>false</param-value>
</jsp-param>
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>-1</param-value>
</jsp-param>
Comman in ANT build file is below:
<java classname="weblogic.jspc" fork="yes" classpath="${esc2.classpath}">
               <arg line="-webapp ${esc.buildwardir} -compileAll -compiler javac -d ${esc.buildwardir.classes} -k"/>
               <arg line="-J-mx256m"/>
          </java>

Hi,
If the classes are still being recompiled then you are running different WLS versions - make sure you are compiling your classes using the same release & version as the one to which you are deploying
You can have a look at the below URL for further information
http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs81/jsp/reference.html

Similar Messages

  • Precompile JSP in WEB-INF

    Hi,
    We're using split-directory. Our jsps live inside of WEB-INF to protect them from
    direct accessing. Only the Servlet controller can access jsps. A few questions
    here:
    1. How can I precompile jsps at the compilation time? Appc doesn't work, since
    it assumes jsps always live outside of the WEB-INF.
    2. Where is the output directory that we should set if we can precompile. Our
    jsps are located in WEB-INF/jsps.
    3. Right now we leave the server compile them on fly. But where the compiled classes
    are stored on the server. We deploy the EAR to the server.
    Thanks!

    Hi,
    1) Thanks for pointing this out. Indeed appc & jspc (8.1) don't compile jsps
    under WEB-INF and the CR associated with this bug is CR133172. Please
    contact [email protected] to obtain a patch for this issue.
    2) If appc were used on a split directory ear, the .class files for the
    jsps are copied into the destination directory of the split dir (more
    specifically into the webapp module's WEB-INF/classes being compiled)
    3) When compiled at runtime, the default outputDirectory is under the server
    temp dirs : .wlnotdelete/extract/<server-name>_<app/ear-name>_<module-name>/
    --Nagesh
    "Kelly" <[email protected]> wrote in message
    news:40771782$[email protected]..
    >
    Hi,
    We're using split-directory. Our jsps live inside of WEB-INF to protectthem from
    direct accessing. Only the Servlet controller can access jsps. A fewquestions
    here:
    1. How can I precompile jsps at the compilation time? Appc doesn't work,since
    it assumes jsps always live outside of the WEB-INF.
    2. Where is the output directory that we should set if we can precompile.Our
    jsps are located in WEB-INF/jsps.
    3. Right now we leave the server compile them on fly. But where thecompiled classes
    are stored on the server. We deploy the EAR to the server.
    Thanks!

  • How can WLS use JSP pages in a Web Application witth just a JRE [Web Application, WAR, JSP, weblogic.jsp.pageCheckSeconds and JRE]

              How can WLS use JSP pages in a Web Application (either a .war file or a war directory structure) without a java compiler?
              I suspect either the JSP specification is flawed (i.e. it doesn't take account of servers using just a JRE), or BEA's implementation is broken.
              Production servers do not have a JDK installed. They only have a JRE. Therfore a java compiler is not present on the machine that the Web Application is deployed onto.
              On the development machine, when the server is requested to load the JSP it creates a tmpwar directory within the Web Application directory structure. This is then included in the resultant .war file thus:
              D:\war>jar -tf gmi.war
              META-INF/
              META-INF/MANIFEST.MF
              gmiService.jsp
              WEB-INF/
              WEB-INF/classes/
              WEB-INF/classes/com/
              WEB-INF/classes/com/bt/
              WEB-INF/classes/com/bt/gmi/
              WEB-INF/classes/com/bt/gmi/gmiService.class
              WEB-INF/getList.xsl
              WEB-INF/getListByConnection.xsl
              WEB-INF/getListByDistrict.xsl
              WEB-INF/getListByDistrictConnection.xsl
              WEB-INF/lib/
              WEB-INF/source/
              WEB-INF/source/build.bat
              WEB-INF/source/gmiService.java
              WEB-INF/web.xml
              WEB-INF/weblogic.xml
              tmpwar/
              tmpwar/jsp_servlet/
              tmpwar/jsp_servlet/_gmiservice.class
              tmpwar/jsp_servlet/_gmiservice.java
              When deployed on the production server with the web.xml file set to use the following values (note XML stripped):
              weblogic.jsp.pageCheckSeconds
              -1
              weblogic.jsp.precompile
              false
              weblogic.jsp.compileCommand
              javac
              weblogic.jsp.verbose
              true
              weblogic.jsp.packagePrefix
              jsp_servlet
              weblogic.jsp.keepgenerated
              false
              And in the weblogic.properties file:
              weblogic.httpd.webApp.gmi=war/gmi
              I've also tried with the .war file, but that insists on creating another tmpwar directory outside of the .war file.
              Then, although I have set pageCheckSeconds to -1 (don't check and don't recompile) ter production server still attempts to recompile the JSP's:
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: init
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param verbose initialized to: true
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param packagePrefix initialized to: jsp_servlet
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param compileCommand initialized to: javac
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param srcCompiler initialized to weblogic.jspc
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param superclass initialized to null
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param workingDir initialized to: /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param pageCheckSeconds initialized to: -1
              Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: initialization complete
              Mon Sep 25 11:40:12 BST 2000:<I> <WebAppServletContext-gmi> Generated java file: /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.java
              Mon Sep 25 11:40:14 BST 2000:<E> <WebAppServletContext-gmi> Compilation of /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.java failed: Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/javac/Main
              java.io.IOException: Compiler failed executable.exec([Ljava.lang.String;[javac, -classpath, /opt/Solaris_JRE_1.2.1_04/lib/rt.jar:/opt/Solaris_JRE_1.2.1_04/lib/i18n.jar:/opt/Solaris_JRE_1.2.1_04/classes:/var/wls/5.1/weblogic/lib/weblogic510sp4boot.jar:/var/wls/5.1/weblogic/classes/boot:/var/wls/5.1/weblogic/eval/cloudscape/lib/cloudscape.jar:/var/wls/5.1/weblogic/lib/wleorb.jar:/var/wls/5.1/weblogic/lib/wlepool.jar:/var/wls/5.1/weblogic/lib/weblogic510sp4.jar:/var/wls/5.1/weblogic/license:/var/wls/5.1/weblogic/classes:/var/wls/5.1/weblogic/lib/weblogicaux.jar:/opt/wls-servers/gmiServer/weblogic/gmiServer/serverclasses:/opt/wls-servers/gmiServer/weblogic/lotusxsl.jar:/opt/wls-servers/gmiServer/weblogic/xerces.jar:/opt/wls-servers/gmiServer/weblogic/logging.jar::/opt/wls-servers/gmiServer/weblogic/war/gmi/WEB-INF/classes:/opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war, -d, /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war, /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.java])
              at java.lang.Throwable.fillInStackTrace(Native Method)
              at java.lang.Throwable.fillInStackTrace(Compiled Code)
              at java.lang.Throwable.<init>(Compiled Code)
              at java.lang.Exception.<init>(Compiled Code)
              at java.io.IOException.<init>(Compiled Code)
              at weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(Compiled Code)
              at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:200)
              at weblogic.servlet.jsp.JspStub.compilePage(Compiled Code)
              at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:173)
              at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:187)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:118)
              at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:142)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:744)
              at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:692)
              at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:251)
              at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:363)
              at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:263)
              at weblogic.kernel.ExecuteThread.run(Compiled Code)
              

    The default Java compiler from sun lives in the tools.jar that comes with
              the JDK. Just add that to your set of JARs which are deployed in production
              and you should be fine. No need to install the full JDK - just make the
              tools.jar available to WebLogic.
              Regards
              James
              James Strachan
              =============
              email: [email protected]
              web: http://www.metastuff.com
              "Martin Webb" <[email protected]> wrote in message
              news:[email protected]...
              >
              > How can WLS use JSP pages in a Web Application (either a .war file or a
              war directory structure) without a java compiler?
              >
              > I suspect either the JSP specification is flawed (i.e. it doesn't take
              account of servers using just a JRE), or BEA's implementation is broken.
              >
              > Production servers do not have a JDK installed. They only have a JRE.
              Therfore a java compiler is not present on the machine that the Web
              Application is deployed onto.
              >
              > On the development machine, when the server is requested to load the JSP
              it creates a tmpwar directory within the Web Application directory
              structure. This is then included in the resultant .war file thus:
              >
              > D:\war>jar -tf gmi.war
              > META-INF/
              > META-INF/MANIFEST.MF
              > gmiService.jsp
              > WEB-INF/
              > WEB-INF/classes/
              > WEB-INF/classes/com/
              > WEB-INF/classes/com/bt/
              > WEB-INF/classes/com/bt/gmi/
              > WEB-INF/classes/com/bt/gmi/gmiService.class
              > WEB-INF/getList.xsl
              > WEB-INF/getListByConnection.xsl
              > WEB-INF/getListByDistrict.xsl
              > WEB-INF/getListByDistrictConnection.xsl
              > WEB-INF/lib/
              > WEB-INF/source/
              > WEB-INF/source/build.bat
              > WEB-INF/source/gmiService.java
              > WEB-INF/web.xml
              > WEB-INF/weblogic.xml
              > tmpwar/
              > tmpwar/jsp_servlet/
              > tmpwar/jsp_servlet/_gmiservice.class
              > tmpwar/jsp_servlet/_gmiservice.java
              >
              > When deployed on the production server with the web.xml file set to use
              the following values (note XML stripped):
              >
              > weblogic.jsp.pageCheckSeconds
              > -1
              >
              > weblogic.jsp.precompile
              > false
              >
              > weblogic.jsp.compileCommand
              > javac
              >
              > weblogic.jsp.verbose
              > true
              >
              > weblogic.jsp.packagePrefix
              > jsp_servlet
              >
              > weblogic.jsp.keepgenerated
              > false
              >
              >
              > And in the weblogic.properties file:
              >
              > weblogic.httpd.webApp.gmi=war/gmi
              >
              > I've also tried with the .war file, but that insists on creating another
              tmpwar directory outside of the .war file.
              >
              >
              > Then, although I have set pageCheckSeconds to -1 (don't check and don't
              recompile) ter production server still attempts to recompile the JSP's:
              >
              >
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: init
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              verbose initialized to: true
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              packagePrefix initialized to: jsp_servlet
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              compileCommand initialized to: javac
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              srcCompiler initialized to weblogic.jspc
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              superclass initialized to null
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              workingDir initialized to:
              /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp: param
              pageCheckSeconds initialized to: -1
              > Mon Sep 25 11:40:11 BST 2000:<I> <WebAppServletContext-gmi> *.jsp:
              initialization complete
              > Mon Sep 25 11:40:12 BST 2000:<I> <WebAppServletContext-gmi> Generated java
              file:
              /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.
              java
              > Mon Sep 25 11:40:14 BST 2000:<E> <WebAppServletContext-gmi> Compilation of
              /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.
              java failed: Exception in thread "main" java.lang.NoClassDefFoundError:
              sun/tools/javac/Main
              >
              > java.io.IOException: Compiler failed
              executable.exec([Ljava.lang.String;[javac, -classpath,
              /opt/Solaris_JRE_1.2.1_04/lib/rt.jar:/opt/Solaris_JRE_1.2.1_04/lib/i18n.jar:
              /opt/Solaris_JRE_1.2.1_04/classes:/var/wls/5.1/weblogic/lib/weblogic510sp4bo
              ot.jar:/var/wls/5.1/weblogic/classes/boot:/var/wls/5.1/weblogic/eval/cloudsc
              ape/lib/cloudscape.jar:/var/wls/5.1/weblogic/lib/wleorb.jar:/var/wls/5.1/web
              logic/lib/wlepool.jar:/var/wls/5.1/weblogic/lib/weblogic510sp4.jar:/var/wls/
              5.1/weblogic/license:/var/wls/5.1/weblogic/classes:/var/wls/5.1/weblogic/lib
              /weblogicaux.jar:/opt/wls-servers/gmiServer/weblogic/gmiServer/serverclasses
              :/opt/wls-servers/gmiServer/weblogic/lotusxsl.jar:/opt/wls-servers/gmiServer
              /weblogic/xerces.jar:/opt/wls-servers/gmiServer/weblogic/logging.jar::/opt/w
              ls-servers/gmiServer/weblogic/war/gmi/WEB-INF/classes:/opt/wls-servers/gmiSe
              rver/weblogic/war/gmi/_tmp_war, -d,
              /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war,
              /opt/wls-servers/gmiServer/weblogic/war/gmi/_tmp_war/jsp_servlet/gmiService.
              java])
              > at java.lang.Throwable.fillInStackTrace(Native Method)
              > at java.lang.Throwable.fillInStackTrace(Compiled Code)
              > at java.lang.Throwable.<init>(Compiled Code)
              > at java.lang.Exception.<init>(Compiled Code)
              > at java.io.IOException.<init>(Compiled Code)
              > at
              weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(Compiled Code)
              > at
              weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:200)
              > at weblogic.servlet.jsp.JspStub.compilePage(Compiled Code)
              > at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:173)
              > at
              weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:18
              7)
              > at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
              :118)
              > at
              weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
              :142)
              > at
              weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
              l.java:744)
              > at
              weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
              l.java:692)
              > at
              weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
              Manager.java:251)
              > at
              weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:363)
              > at
              weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:263)
              > at weblogic.kernel.ExecuteThread.run(Compiled Code)
              >
              >
              >
              

  • Precompiled JSP not taken in account by Weblogic 10.3.1

    Hi
    My JSPs are properly precompiled in my ear, and well taken in account by weblogic when I work with my local environment. But if I upload my ear on the Unix server, they're not taken in account anymore. Weblogic compiles them in real time, that causes a display time really long for each page.
    The precompiled JSP are present in the folder WEB-INF/classes/jsp_servlet/_jsp , inside the file app-web.war, itself included in the ear.
    Once the ear is deployed on the server, I find my precompiled JSP at 2 places :
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/rdi76c/war/WEB-INF/lib/_wl_cls_gen.jar
    then in jsp_servlet/_jsp
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/m8l8j8/app-web.war
    then in WEB-INF\classes\jsp_servlet\_jsp\
    At the execution time, Weblogic should be able to find the precompiled JSP at that 2 places. However, it recompiles the JSPs and places them here :
    - <domain>/servers/<server>/tmp/_WL_user/<ear_name>/rdi76c/jsp_servlet/_jsp
    I have already checked the dates. The dates written in the generated .java files match the system dates of the corresponding JSP files. It could have been an explanation, but it's not.
    Do you have any idea ?

    but encounter version mismatching error... It indicated that it only support 10.3.0... It's hard to tell based on your description, but I am going to guess that you are not selecting the right version of WLS runtime in the new runtime wizard. WLS 10.3.1 is also known as WLS 11gR1. Make sure that you look for it in Oracle rather than BEA category.
    - Konstantin

  • Precompiling JSPs Outside Weblogic Home Directory

    Using Weblogic Server 9.2. Was able to precompile JSPs in a war file with weblogic.appc at the command line with only the weblogic.jar inside the Weblogic installation directory in my classpath. I then translated this into an Ant task, and because the script may need to run on a box that does not have Weblogic installed, copied weblogic.jar to my build area and included that one in my classpath. It immediately began throwing NoClassDefFound exceptions. Discovered the "Class-Path" list of additional jars in the MANIFEST inside weblogic.jar, searched these jars and found all of the missing classes--except for the last one. The missing class is org/apache/bcelx/classfile/ClassParser, and the error I'm getting is "WARNING: unable to get an input stream for jar:file:D:\APPS\Java\jdk1.5.0_13\jre\lib\rt.jar!" followed by java.lang.NoClassDefFoundError. The error occurs in javelin.java.JavaClassFile.getParseTree() at line 178. There is a BCEL Apache project, but they have no mention of BCELX on their website. Anyone know where I can find this class, or source code for javelin.java.JavaClassFile?
    Edited by willhandley at 06/06/2008 10:25 AM

    I tried the wlappc target:
    <target name="_precompile-jsp">
         <taskdef name="wlappc" classname="weblogic.ant.taskdefs.j2ee.Appc" classpathref="class.path" />
         <echo message="Precompiling JSPs in ${appfile}"/>
              <wlappc source="${appfile}" debug="true" verbosejavac="true" verbose="true" runtimeflags="-J-ms1024m -J-mx2048m"/>
    </target>
    But I keep getting:
    [java] [wlappc] java.lang.OutOfMemoryError: Java heap space
    We've got quite a lot of jsps in our application. It seems the memory options are being ignored and it seems other people have experienced the same problem with the memory options being ignored when using wlappc and have switched to weblogic.appc.
    When I switch to weblogic.appc I don't get the out of memory issue, though of course I'm still getting the initial stack trace reported. Any other ideas?

  • Redeploy precompiled JSPs to managed server in exploded format without incurring a JSP recompile

         How do you redeploy precompiled JSPs to a managed server in exploded format without
    incurring a JSP recompile?
         Our application is deployed in Two Phase, Stage mode, Exploded Format. We regularly
    update JSPs on our Production application and would like to be able to redeploy
    JSPs without incurring the JSP recompile. I am able to precompile JSPs and redeploy
    the JSP and compiled JSP to the managed server, but the updated page is still
    recompiled.
         I've searched the BEA site, newsgroups, and web and still need some help.
         Additional information:
         - precompile in web.xml is false. we'd prefer not to precompile all the jsps
    at startup to minimize Production downtimes when deploying new major releases
         - the compiled JSPs reside in ~/classes/jsp_servlet and not ~/WEB-INF/classes/jsp_servlet
         - our directory structure looks like:
              ~/app
                   /META-INF
                   /WEB-INF
                   /classes ( compiled source )
                        /hotwire ( java class files )
                        /jsp_servlet ( compiled jsps )
              ~/deploy ( property files )
                   /prod
                        /web.xml
                        /weblogic.xml
              ~/src ( java files )
                   hotwire/
         I found this information on the BEA newsgroup ( http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.jsp&item=582&utag=
    ) regarding the _isStale() method for compiled JSPs, but wasn't able to get it
    to work when the file was in the exact same path ( note: compilation occurred
    on a different machine than the managed view server )
         Do we have to store our compiled JSP files under /WEB-INF/classes for this feature
    to work and in a WAR?
         What am I missing?
         Regards,
              Paul

    Hi Mark,
    Thank you for replying and logging the CR. I've read lots of your posts in researching
    this issue and was hoping you'd reply.
    I used the JSP Precompile Validation Utility ( http://dev2dev.bea.com/resourcelibrary/utilitiestools/adminmgmt.jsp
    ) and tested against WLS8.1sp2 and agree with your assessment. The JSP Time utility
    indicates that the JSP and compiled class are in agreement, yet the server always
    recompiled the JSP after I redeployed that particular file and class. I opened
    Case Ticket #: 473459 that includes a test script, output, and lots of information.
    It's currently being investigated. I'll inform the BEA Relations engineer and
    add my name to the CR you opened.
    Dynamic content updates without recompiles is something we'd really like to be
    able to do. We are hoping to be able to do specific frequent content updates
    in the afternoon as opposed to 1:00 AM :)
    Thanks again,
    Paul
    JSP TIME TOOL:
    Summary
    ====================
    Total JSP Files: 1
    Total JSP that will compile in server because of missing _staticIsStale method:....
    0
    Total JSP that will compile in server because of wrong weblogic version:...........
    0
    Total JSP that will compile in server because jsp is newer than parse date:........
    0
    Total JSP that will compile in server because missing class:.......................
    0
    REDEPLOY COMMAND:
    $JAVA weblogic.Deployer -adminurl t3://localhost:7004 -user <username> -password
    <password> -name phoenixApp -targets phoenixViewWebApp@wlview1 -redeploy web/jsp/customer-care/indexMain.jsp
    WEB-INF/classes/jsp_servlet/_web/_jsp/_customer_45_care/__indexmain.jsp
    WEBLOGIC LOG:
    ####<Jan 13, 2004 3:33:04 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
    '2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149059> <Module
    phoenixViewWebApp of application phoenixApp is transitioning from active to prepared
    on server wlview1.>
    ####<Jan 13, 2004 3:33:04 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
    '2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149060> <Module
    phoenixViewWebApp of application phoenixApp successfully transitioned from active
    to prepared on server wlview1.>
    ####<Jan 13, 2004 3:33:05 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
    '2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149059> <Module
    phoenixViewWebApp of application phoenixApp is transitioning from prepared to
    active on server wlview1.>
    ####<Jan 13, 2004 3:33:05 PM PST> <Info> <Deployer> <ppjsp01> <wlview1> <ExecuteThread:
    '2' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149060> <Module
    phoenixViewWebApp of application phoenixApp successfully transitioned from prepared
    to active on server wlview1.>
    ####<Jan 13, 2004 3:38:13 PM PST> <Info> <HTTP> <ppjsp01> <wlview1> <ExecuteThread:
    '119' for queue: 'default'> <<anonymous>> <> <BEA-101295> <Recompiling JSP [ServletContext(id=31702491,name=phoenixViewWebApp,context-path=)],
    resource [web/jsp/customer-care/indexMain.jsp], because it is stale. It was previously
    compiled using a different version of WebLogic Server.
    JSP build version: 8.1.2.0
    WLS build version: 8.1.2.0.>
    ####<Jan 13, 2004 3:38:13 PM PST> <Info> <HTTP> <ppjsp01> <wlview1> <ExecuteThread:
    '119' for queue: 'default'> <<anonymous>> <> <BEA-101047> <[ServletContext(id=31702491,name=phoenixViewWebApp,context-path=)]
    Generated java file: /opt/p4/phoenix/6.2/app/WEB-INF/classes/jsp_servlet/_web/_jsp/_customer_45_care/__indexmain.java>
    "Mark Griffith" <[email protected]> wrote:
    So this is a scenario that we should support Paul.
    There are a couple of issues.
    1) I dont think our weblogic.Deployer api currently does a very good
    job of
    this at all, since it is MOSTLY concerned with redeployment of applications
    and modules, and in this scenario you dont want app redpeloyment you
    just
    want what are essentially content files distributed. In otherwords the
    api
    I worry wont help you distributing files for this case, at least in this
    current release and SP.
    2) once you get the files to the location, things should in the servlet
    containers.
    Having said that it is easier if you are able to have the application's
    deployed with -no-stage, or no-copying, or shared application, that way
    you
    have one location to copy files to vs. many stage dirs. Either way you'll
    have to copy the jsp's and the classfiles to the webapp directories.
    Additionally I just tried this on 8.1. sp2 and the stale-check by the
    servlet container is busted. :( I opened a bug on this: CR133453.
    Not
    sure if this is in sp1 or not, didnt have time to check it. I suggest
    you
    contact support and get your name added to this CR to raise its priority.
    Cheers
    mbg

  • Weblogic Recompiles Already Pre-compiled JSPs

              I have pre-compiled all the JSPs in our WebApp. Unfortunately, when I hit the
              JSP from the Browser, Weblogic is re-compiling it again. I must not be placing
              the compiled JSP (.class files) in the correct location. Or I could be missing
              a flag or something.
              I am using an exploded directory format and have also tried War file as well.
              - file is ./prodssl/account/login.jsp
              - class in ./prodssl/WEB-INF/classfiles/jsp_servlet/_account/__login.class
              - tried ./prodssl/WEB-INF/jsp_servlet/_account/__login.class
              - tried ./prodssl/WEB-INF/classfiles/__login.class
              Weblogic recompiles it into ....\wl_comp....\WEB-INF\_tmp_war_......\jsp_servlet\_account.
              Any Ideas?
              PS - I just saw the -depend option that I will in a sec. Don't know if it will
              help or not.
              Thanks. Later...
              - Wayne
              

              I have changed the directory from classfiles to classes, but that doesn't seem
              to fix the problem. Is there anything else I need to do? Other parameters or
              changes to xml files?
              Since JSPs are compiled into Servlets, do I need to register them as such? I've
              tried registering the it as a servlet, but it doesn't seem to pick it up. Then
              again, I probably have the mapping incorrect or something; if that is what I need
              to do.
              Thanks. Later...
              - Wayne
              "Wayne Lau" <[email protected]> wrote:
              >
              >Thanks All.
              >
              >I'm using WLS 6.1 sp1.
              >
              >I was using classFiles b/c that what I saw Weblogic use when it compiled
              >the JSPs.
              >
              >Thanks again. Later...
              >
              >
              >- Wayne
              >
              >
              >
              >Nils Winkler <[email protected]> wrote:
              >>Hi,
              >>
              >>the location for your files should be
              >>
              >>WEB-INF/classes/jsp_servlet/_account
              >>
              >>You're using "classfiles" instead of "classes", which probably is the
              >>cause for your problem.
              >>
              >>Also set the value of pageCheckSeconds to -1 in your weblogic.xml file.
              >>This will disable recompilation of the files:
              >>
              >> <jsp-descriptor>
              >> <jsp-param>
              >> <param-name>pageCheckSeconds</param-name>
              >> <param-value>-1</param-value>
              >> </jsp-param>
              >> </jsp-descriptor>
              >>
              >>Hope that helps,
              >>
              >>Nils
              >>
              >>Wayne Lau wrote:
              >>>
              >>> I have pre-compiled all the JSPs in our WebApp. Unfortunately, when
              >>I hit the
              >>> JSP from the Browser, Weblogic is re-compiling it again. I must not
              >>be placing
              >>> the compiled JSP (.class files) in the correct location. Or I could
              >>be missing
              >>> a flag or something.
              >>>
              >>> I am using an exploded directory format and have also tried War file
              >>as well.
              >>>
              >>> - file is ./prodssl/account/login.jsp
              >>> - class in ./prodssl/WEB-INF/classfiles/jsp_servlet/_account/__login.class
              >>> - tried ./prodssl/WEB-INF/jsp_servlet/_account/__login.class
              >>> - tried ./prodssl/WEB-INF/classfiles/__login.class
              >>>
              >>> Weblogic recompiles it into ....\wl_comp....\WEB-INF\_tmp_war_......\jsp_servlet\_account.
              >>> Any Ideas?
              >>>
              >>> PS - I just saw the -depend option that I will in a sec. Don't know
              >>if it will
              >>> help or not.
              >>>
              >>> Thanks. Later...
              >>>
              >>> - Wayne
              >>
              >>--
              >>============================
              >>[email protected]
              >
              

  • Re: Precompiling JSP with admin/managed servers

    Thanks, but I'm not doing any copying.
              The admin/managed-server communication copies things to the managed server,
              which then always recompiles the pages when hit.
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              "Robert Coonrad" <[email protected]> wrote in message
              news:[email protected]...
              >
              > check out post 8366...i found that i was not preserving
              > the lastmodified date on my jsps and this was causing
              > unnecessary re-compilation.
              >
              > hope it helps...
              > bobc
              >
              > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >I believe I have exhausted all permutations of EARing/notEARing,
              > >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              > >placing them in a static location and setting workingDir to that
              location,
              > >combinations of the above.
              > >
              > >No matter what, the managed server re-compiles pages the first time they
              > >are
              > >hit. Non admin/managed-server I have no problems.
              > >
              > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >for
              > >getting a cluster working with precompiled jsps?
              > >
              > >-Greg
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              > >> fighting the "staleness" checker in WL. I've been through all of the
              > >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              > >> pre-compilation working on single-server deployments, but admin/managed
              > >> server deployments have me beat.
              > >>
              > >> WL6.1, SP1, Solaris
              > >>
              > >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              > >> place. The fixed place contains pre-compiled versions of all jsps
              > >made on
              > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >in the
              > >> exploded EAR file used by the admin server as the model for managed
              > >> servers.. The managed servers are on the same machine.
              > >>
              > >> When the admin server gives an application to a managed server, the
              > >managed
              > >> server creates a temporary directory containing all of the webapp
              > >> components, etc. The file timestamps on these files is the set by
              > >the
              > >> copying process to the time of the managed server boot (why?!?!????!?),
              > >so
              > >> the staleness check always thinks they are new and could care less
              > >what
              > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              directory,
              > >or
              > >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              > >in
              > >> this scenario.
              > >>
              > >> If I tell the managed server to precompile everything on boot (about
              > >45
              > >> minutes for this app) it will create versions of the classes that match
              > >th
              > >e
              > >> new JSP file timestamps, but this does not even survive a reboot of
              > >the
              > >> managed server because it AGAIN creates a new temp version of
              everything
              > >on
              > >> the next reboot with new timestamps.
              > >>
              > >> If I wait for the managed server to boot and find the directory like
              > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >copy
              > >> (via cp -pr to retain timestamps) all of the original webapp components
              > >on
              > >> top of the temp versions, the staleness checker is happy and the
              > >> pre-compiled versions work fine.
              > >>
              > >> There HAS to be a way to package pre-compiled versions of the JSPs
              > >in the
              > >> "model" application in the admin server and keep from having to
              precompile
              > >> the JSPs on every managed server every time managed server is booted..
              > >>
              > >> It would help if we had a way to bypass the staleness checking
              > >completely..
              > >> Or you guys should make the timestamps on the files copied by the
              > >> admin/managed deployment process match properly so the staleness
              checker
              > >> doesn't think the JSP is different.
              > >>
              > >> It would also help if the engineer who wrote this could explain the
              > >rules
              > >> being implemented by the staleness checker. So far all the messages
              > >in
              > >the
              > >> newsgroup have amounted to point solutions for problems without a good
              > >> understanding of what the engine is checking for and/or doing under
              > >the
              > >> covers. Looking at the generated .java files for the JSP pages helps,
              > >but
              > >> it is not good enough...
              > >>
              > >> Anyone out there have a working admin/managed server JSP application?
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >>
              > >>
              > >
              > >
              >
              

    The admin/managed-server communication copies things to the managed server, which then always recompiles the pages when hit.
              This is a known issue and is fixed. The timestamps of the compiled classes was not being preserved when extracted from the war file used to distribute to the managed servers. This will be available in WLS6.1 Service Pack 3 - and there is a temporary patch available for SP2. Please ask your friendly BEA support person for it (you can refer to CR058946)
              I'd give you the patch myself, but they like to keep track of these things...
              Regards,
              Alex
              "Girish" <[email protected]> wrote in message news:[email protected]...
              >
              > "Aditya Kiran Gavvala" <[email protected]> wrote:
              > >Greg,
              > >
              > >I have been following your posts, because our application deployment
              > >ran
              > >into exact same problem you ran into. I had spent a full two days
              > >researching into the problem. And I figured the solution. Hope this
              > >helps.
              > >
              > >Here are my discoveries:
              > >
              > >The following applies only to the following environment:
              > >OS: Linux (perhaps for Win/Unix/Solaris etc)
              > >WLS 6.0 SP2 ( no rolling patches): I found Rolling Patch2 (RP2) not useful
              > >for this problem.
              > >Clustered environment with Admin/Managed servers
              > >
              > >- When you compile JSP using weblogic.jspc compiler it puts the JSP file
              > >timestamp into the compiled class. You can see it in the generated java
              > >file
              > >(you need to supply -keepgenerated switch to jspc)
              > >
              > >- When a request is made to a JSP page after the application is deployed,
              > >it
              > >seems to be retrieving this timestamp from the compiled class file and
              > >comparing it with the JSP file timestamp. If they dont match a compile
              > >command gets run by the server. Thereby you see a compile happening at
              > >run
              > >time.
              > >
              > >- If you have exploded directory deployment, when you start the managed
              > >servers they create a ".war" file (under some temp dir) with all the
              > >JSP
              > >source files going into the file. You can notice this by looking into
              > >the
              > >server log file. Therefore all JSP source files get a brand new timestamp
              > >in
              > >the archive (a timestamp later than what was put class files by
              > >weblogic.jspc). So, the server at run time sees that the timestamp in
              > >the
              > >class file is older than the JSP source file and runs a recompile. So
              > >DONT
              > >DO EXPLODED directory deployment if your environment is as described
              > >in this
              > >post.
              > >
              > >- If you have ".war" file deployment, you will not have a problem. At
              > >the
              > >start up time managed server still creates "".war" file under a temp
              > >directory however it seems to be copying the content of the your ".war"
              > >file. So, the timestamps of JSP remain the same as they were before.
              > >SO NO
              > >RE-COMPILATION.
              > >
              > >- Another important thing to remember is to make sure you specify the
              > >workingDir in the weblogic.xml file. That is where the precompiled class
              > >files should reside. This should be any directory the server uses as
              > >scratch
              > >pad to compile classes or find (pre)compiled classes. This is not a
              > >directory inside your .war file is what I am trying to get at.
              > >
              > >Hope this helps,
              > >Aditya
              > >
              > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >news:[email protected]...
              > >> Thanks, but I'm not doing any copying.
              > >>
              > >> The admin/managed-server communication copies things to the managed
              > >server,
              > >> which then always recompiles the pages when hit.
              > >>
              > >> -Greg
              > >>
              > >> -----------------------------------------------------------
              > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >>
              > >> "Robert Coonrad" <[email protected]> wrote in message
              > >> news:[email protected]...
              > >> >
              > >> > check out post 8366...i found that i was not preserving
              > >> > the lastmodified date on my jsps and this was causing
              > >> > unnecessary re-compilation.
              > >> >
              > >> > hope it helps...
              > >> > bobc
              > >> >
              > >> > "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              > >> > >I believe I have exhausted all permutations of EARing/notEARing,
              > >> > >WARing/notWARing, placing precompiled jsp class files in
              > >WEB-INF/classes,
              > >> > >placing them in a static location and setting workingDir to that
              > >> location,
              > >> > >combinations of the above.
              > >> > >
              > >> > >No matter what, the managed server re-compiles pages the first time
              > >they
              > >> > >are
              > >> > >hit. Non admin/managed-server I have no problems.
              > >> > >
              > >> > >Can anyone from BEA comment on this problem? Or give me a workaround
              > >> > >for
              > >> > >getting a cluster working with precompiled jsps?
              > >> > >
              > >> > >-Greg
              > >> > >
              > >> > >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              > >> > >news:[email protected]...
              > >> > >> Grrr... The JSP engine is extremely frustrating! I've spent many
              > >hours
              > >> > >> fighting the "staleness" checker in WL. I've been through all
              > >of the
              > >> > >> newsgroup messages pertaining to pre-compiling, etc., and I've
              > >gotten
              > >> > >> pre-compilation working on single-server deployments, but
              > >admin/managed
              > >> > >> server deployments have me beat.
              > >> > >>
              > >> > >> WL6.1, SP1, Solaris
              > >> > >>
              > >> > >> I've done the pageCheckSeconds=-1 and the workingDir is set to
              > >a
              > >fixed
              > >> > >> place. The fixed place contains pre-compiled versions of all
              > >jsps
              > >> > >made on
              > >> > >> that machine using jspc not 20 minutes earlier using the JSP files
              > >> > >in the
              > >> > >> exploded EAR file used by the admin server as the model for managed
              > >> > >> servers.. The managed servers are on the same machine.
              > >> > >>
              > >> > >> When the admin server gives an application to a managed server,
              > >the
              > >> > >managed
              > >> > >> server creates a temporary directory containing all of the webapp
              > >> > >> components, etc. The file timestamps on these files is the set
              > >by
              > >> > >the
              > >> > >> copying process to the time of the managed server boot
              > >(why?!?!????!?),
              > >> > >so
              > >> > >> the staleness check always thinks they are new and could care
              > >less
              > >> > >what
              > >> > >> precompiled jsps I have in my workingDir, the WEB-INF/classes
              > >> directory,
              > >> > >or
              > >> > >> anywhere else. The pageCheckSeconds=-1 seems to be completely
              > >ignored
              > >> > >in
              > >> > >> this scenario.
              > >> > >>
              > >> > >> If I tell the managed server to precompile everything on boot
              > >(about
              > >> > >45
              > >> > >> minutes for this app) it will create versions of the classes that
              > >match
              > >> > >th
              > >> > >e
              > >> > >> new JSP file timestamps, but this does not even survive a reboot
              > >of
              > >> > >the
              > >> > >> managed server because it AGAIN creates a new temp version of
              > >> everything
              > >> > >on
              > >> > >> the next reboot with new timestamps.
              > >> > >>
              > >> > >> If I wait for the managed server to boot and find the directory
              > >like
              > >> > >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              > >> > >copy
              > >> > >> (via cp -pr to retain timestamps) all of the original webapp
              > >components
              > >> > >on
              > >> > >> top of the temp versions, the staleness checker is happy and the
              > >> > >> pre-compiled versions work fine.
              > >> > >>
              > >> > >> There HAS to be a way to package pre-compiled versions of the
              > >JSPs
              > >> > >in the
              > >> > >> "model" application in the admin server and keep from having to
              > >> precompile
              > >> > >> the JSPs on every managed server every time managed server is
              > >booted..
              > >> > >>
              > >> > >> It would help if we had a way to bypass the staleness checking
              > >> > >completely..
              > >> > >> Or you guys should make the timestamps on the files copied by
              > >the
              > >> > >> admin/managed deployment process match properly so the staleness
              > >> checker
              > >> > >> doesn't think the JSP is different.
              > >> > >>
              > >> > >> It would also help if the engineer who wrote this could explain
              > >the
              > >> > >rules
              > >> > >> being implemented by the staleness checker. So far all the messages
              > >> > >in
              > >> > >the
              > >> > >> newsgroup have amounted to point solutions for problems without
              > >a
              > >good
              > >> > >> understanding of what the engine is checking for and/or doing
              > >under
              > >> > >the
              > >> > >> covers. Looking at the generated .java files for the JSP pages
              > >helps,
              > >> > >but
              > >> > >> it is not good enough...
              > >> > >>
              > >> > >> Anyone out there have a working admin/managed server JSP application?
              > >> > >> -Greg
              > >> > >>
              > >> > >> -----------------------------------------------------------
              > >> > >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              > >> > >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              > >> > >>
              > >> > >>
              > >> > >>
              > >> > >
              > >> > >
              > >> >
              > >>
              > >>
              > >
              > >
              >
              [att1.html]
              

  • Reloading precompiled JSP

    Hi,
    We are trying to do this:
    - precompile foo.jsp to foo.class offline;
    - copy foo.class and foo.jsp into a machine weblogic is running,
    maintain their timestamp when they are compiled and generated;
    - when accessing foo.jsp, we hope weblogic will load the precompiled
    foo.class, instead of recompile the foo.jsp again.
    This works well if foo.jsp has not been access (not loaded into
    weblogic yet). BUT, if foo.jsp is accessed before (loaded into
    weblogic), the new foo.jsp is always recompiled.
    We can hot deploy the compiled foo.class using servlet hot deploy,
    but we do not want to use the console. (Is there a command line thing
    to do servlet hot deploy)?
    Is there any other way to do this? The goal -- precompile .jsp,
    server reload the changed .class, never compile .jsp on server.
    We are using WebLogic 5.1.0 with service pack3.
    Any help appreciated.
    Thanks,
    -- Jin

    This is a good question. I will ask the developers.
    Thanks,
    Michael
    Michael Girdley
    Product Manager, WebLogic Server & Express
    BEA Systems Inc
    Jin Hong <[email protected]> wrote in message news:[email protected]..
    >
    Hi,
    We are trying to do this:
    - precompile foo.jsp to foo.class offline;
    - copy foo.class and foo.jsp into a machine weblogic is running,
    maintain their timestamp when they are compiled and generated;
    - when accessing foo.jsp, we hope weblogic will load the precompiled
    foo.class, instead of recompile the foo.jsp again.
    This works well if foo.jsp has not been access (not loaded into
    weblogic yet). BUT, if foo.jsp is accessed before (loaded into
    weblogic), the new foo.jsp is always recompiled.
    We can hot deploy the compiled foo.class using servlet hot deploy,
    but we do not want to use the console. (Is there a command line thing
    to do servlet hot deploy)?
    Is there any other way to do this? The goal -- precompile .jsp,
    server reload the changed .class, never compile .jsp on server.
    We are using WebLogic 5.1.0 with service pack3.
    Any help appreciated.
    Thanks,
    -- Jin

  • Precompiling JSP with admin/managed servers

    Grrr... The JSP engine is extremely frustrating! I've spent many hours
              fighting the "staleness" checker in WL. I've been through all of the
              newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              pre-compilation working on single-server deployments, but admin/managed
              server deployments have me beat.
              WL6.1, SP1, Solaris
              I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              place. The fixed place contains pre-compiled versions of all jsps made on
              that machine using jspc not 20 minutes earlier using the JSP files in the
              exploded EAR file used by the admin server as the model for managed
              servers.. The managed servers are on the same machine.
              When the admin server gives an application to a managed server, the managed
              server creates a temporary directory containing all of the webapp
              components, etc. The file timestamps on these files is the set by the
              copying process to the time of the managed server boot (why?!?!????!?), so
              the staleness check always thinks they are new and could care less what
              precompiled jsps I have in my workingDir, the WEB-INF/classes directory, or
              anywhere else. The pageCheckSeconds=-1 seems to be completely ignored in
              this scenario.
              If I tell the managed server to precompile everything on boot (about 45
              minutes for this app) it will create versions of the classes that match the
              new JSP file timestamps, but this does not even survive a reboot of the
              managed server because it AGAIN creates a new temp version of everything on
              the next reboot with new timestamps.
              If I wait for the managed server to boot and find the directory like
              .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically copy
              (via cp -pr to retain timestamps) all of the original webapp components on
              top of the temp versions, the staleness checker is happy and the
              pre-compiled versions work fine.
              There HAS to be a way to package pre-compiled versions of the JSPs in the
              "model" application in the admin server and keep from having to precompile
              the JSPs on every managed server every time managed server is booted..
              It would help if we had a way to bypass the staleness checking completely..
              Or you guys should make the timestamps on the files copied by the
              admin/managed deployment process match properly so the staleness checker
              doesn't think the JSP is different.
              It would also help if the engineer who wrote this could explain the rules
              being implemented by the staleness checker. So far all the messages in the
              newsgroup have amounted to point solutions for problems without a good
              understanding of what the engine is checking for and/or doing under the
              covers. Looking at the generated .java files for the JSP pages helps, but
              it is not good enough...
              Anyone out there have a working admin/managed server JSP application?
              -Greg
              Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              

              check out post 8366...i found that i was not preserving
              the lastmodified date on my jsps and this was causing
              unnecessary re-compilation.
              hope it helps...
              bobc
              "Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote:
              >I believe I have exhausted all permutations of EARing/notEARing,
              >WARing/notWARing, placing precompiled jsp class files in WEB-INF/classes,
              >placing them in a static location and setting workingDir to that location,
              >combinations of the above.
              >
              >No matter what, the managed server re-compiles pages the first time they
              >are
              >hit. Non admin/managed-server I have no problems.
              >
              >Can anyone from BEA comment on this problem? Or give me a workaround
              >for
              >getting a cluster working with precompiled jsps?
              >
              >-Greg
              >
              >"Greg Nyberg" <greg.nyberg.at.objectpartners.com> wrote in message
              >news:[email protected]...
              >> Grrr... The JSP engine is extremely frustrating! I've spent many hours
              >> fighting the "staleness" checker in WL. I've been through all of the
              >> newsgroup messages pertaining to pre-compiling, etc., and I've gotten
              >> pre-compilation working on single-server deployments, but admin/managed
              >> server deployments have me beat.
              >>
              >> WL6.1, SP1, Solaris
              >>
              >> I've done the pageCheckSeconds=-1 and the workingDir is set to a fixed
              >> place. The fixed place contains pre-compiled versions of all jsps
              >made on
              >> that machine using jspc not 20 minutes earlier using the JSP files
              >in the
              >> exploded EAR file used by the admin server as the model for managed
              >> servers.. The managed servers are on the same machine.
              >>
              >> When the admin server gives an application to a managed server, the
              >managed
              >> server creates a temporary directory containing all of the webapp
              >> components, etc. The file timestamps on these files is the set by
              >the
              >> copying process to the time of the managed server boot (why?!?!????!?),
              >so
              >> the staleness check always thinks they are new and could care less
              >what
              >> precompiled jsps I have in my workingDir, the WEB-INF/classes directory,
              >or
              >> anywhere else. The pageCheckSeconds=-1 seems to be completely ignored
              >in
              >> this scenario.
              >>
              >> If I tell the managed server to precompile everything on boot (about
              >45
              >> minutes for this app) it will create versions of the classes that match
              >th
              >e
              >> new JSP file timestamps, but this does not even survive a reboot of
              >the
              >> managed server because it AGAIN creates a new temp version of everything
              >on
              >> the next reboot with new timestamps.
              >>
              >> If I wait for the managed server to boot and find the directory like
              >> .../applications/.wlnotdelete_man1/wlap7336/webapp/... and physically
              >copy
              >> (via cp -pr to retain timestamps) all of the original webapp components
              >on
              >> top of the temp versions, the staleness checker is happy and the
              >> pre-compiled versions work fine.
              >>
              >> There HAS to be a way to package pre-compiled versions of the JSPs
              >in the
              >> "model" application in the admin server and keep from having to precompile
              >> the JSPs on every managed server every time managed server is booted..
              >>
              >> It would help if we had a way to bypass the staleness checking
              >completely..
              >> Or you guys should make the timestamps on the files copied by the
              >> admin/managed deployment process match properly so the staleness checker
              >> doesn't think the JSP is different.
              >>
              >> It would also help if the engineer who wrote this could explain the
              >rules
              >> being implemented by the staleness checker. So far all the messages
              >in
              >the
              >> newsgroup have amounted to point solutions for problems without a good
              >> understanding of what the engine is checking for and/or doing under
              >the
              >> covers. Looking at the generated .java files for the JSP pages helps,
              >but
              >> it is not good enough...
              >>
              >> Anyone out there have a working admin/managed server JSP application?
              >> -Greg
              >>
              >> -----------------------------------------------------------
              >> Check out my WebLogic 6.1 Workbook for O'Reilly EJB Third Edition
              >> www.oreilly.com/catalog/entjbeans3 or www.titan-books.com
              >>
              >>
              >>
              >
              >
              

  • Precompiling JSPs Programatically

    Does anyone know how we can precompile JSP programatically?
              We are writing a batched java application that will create a series of JSP
              files on a nightly basis. We would like to compile these files when they
              are created to save some time when users hit these scripts for the first
              time.
              Any help would be excellent. Thanks in advance,
              Marcus
              [email protected]
              

    Hi,
              the documentation
              (http://www.weblogic.com/docs51/classdocs/API_jsp.html#compiler) should
              tell you how. It's pretty easy. Personnally I compile the generated java
              with the jikes compiler.
              I'm attaching a UNIX sh script that does this. You won't be able to run
              it because it depends on other scripts and a special setup but you will
              get idea :)
              Mathieu
              Marcus Leon wrote:
              >
              > Does anyone know how we can precompile JSP programatically?
              >
              > We are writing a batched java application that will create a series of JSP
              > files on a nightly basis. We would like to compile these files when they
              > are created to save some time when users hit these scripts for the first
              > time.
              >
              > Any help would be excellent. Thanks in advance,
              >
              > Marcus
              > [email protected]
              [precompileWebApp.sh]
              

  • Error when precompile jsp files

    I tried to precompile my jsp files by adding precompile functionality in my xml
    file and I received this error during startup. Can anyone help?
    java.lang.NullPointerException
    at weblogic.servlet.jsp.Jsp2Java.makeReader(Jsp2Java.java:232)
    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:112)
    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:253
    at weblogic.servlet.jsp.Precompiler.compileOne(Precompiler.java:124)
    at weblogic.servlet.jsp.Precompiler.compile(Precompiler.java:44)
    at weblogic.servlet.internal.WebAppServletContext.precompileJSPs(WebAppS
    ervletContext.java:2003)
    at weblogic.servlet.internal.dd.DescriptorLoader.initFromWebApp(Descript
    orLoader.java:742)
    at weblogic.servlet.internal.dd.DescriptorLoader.createServletContext(De
    scriptorLoader.java:359)
    at weblogic.servlet.internal.HttpServer.loadWARContext(HttpServer.java:4
    67)
    at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:404)
    at weblogic.j2ee.WebAppComponent.deploy(WebAppComponent.java:74)
    at weblogic.j2ee.Application.addComponent(Application.java:133)
    at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:327)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:143)
    at weblogic.management.mbeans.custom.WebServer.addWebDeployment(WebServe
    r.java:76)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    .java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy29.addWebDeployment(Unknown Source)
    at weblogic.management.configuration.WebServerMBean_CachingStub.addWebDe
    ployment(WebServerMBean_CachingStub.java:1012)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:313)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:143)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    .java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBean
    s(ConfigurationMBeanImpl.java:409)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:287)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMB
    eanImpl.java:866)
    at weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMB
    eanImpl.java:853)
    at weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.ja
    va:838)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:566)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    .java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy14.addTarget(Unknown Source)
    at weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(Appli
    cationManager.java:486)
    at weblogic.management.mbeans.custom.ApplicationManager.addApplication(A
    pplicationManager.java:557)
    at weblogic.management.mbeans.custom.ApplicationManager.addApplication(A
    pplicationManager.java:504)
    at weblogic.management.mbeans.custom.ApplicationManager.poll(Application
    Manager.java:428)
    at weblogic.management.mbeans.custom.ApplicationManager.poll(Application
    Manager.java:380)
    at weblogic.management.mbeans.custom.ApplicationManager.update(Applicati
    onManager.java:152)
    at weblogic.management.mbeans.custom.ApplicationManager.startAdminManage
    r(ApplicationManager.java:205)
    at weblogic.management.mbeans.custom.ApplicationManager.start(Applicatio
    nManager.java:120)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    .java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy3.start(Unknown Source)
    at weblogic.management.Admin.startApplicationManager(Admin.java:1037)
    at weblogic.management.Admin.finish(Admin.java:493)
    at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:429)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:170)
    at weblogic.Server.main(Server.java:35)

    is your webapp deployed as .war or as exploded format?
    If it's war, there's a patch available that you can get it by contacting support
    Kumar
    buatapa wrote:
    I tried to precompile my jsp files by adding precompile functionality in my xml
    file and I received this error during startup. Can anyone help?
    java.lang.NullPointerException
    at weblogic.servlet.jsp.Jsp2Java.makeReader(Jsp2Java.java:232)
    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:112)
    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:253
    at weblogic.servlet.jsp.Precompiler.compileOne(Precompiler.java:124)
    at weblogic.servlet.jsp.Precompiler.compile(Precompiler.java:44)
    at weblogic.servlet.internal.WebAppServletContext.precompileJSPs(WebAppS
    ervletContext.java:2003)
    at weblogic.servlet.internal.dd.DescriptorLoader.initFromWebApp(Descript
    orLoader.java:742)
    at weblogic.servlet.internal.dd.DescriptorLoader.createServletContext(De
    scriptorLoader.java:359)
    at weblogic.servlet.internal.HttpServer.loadWARContext(HttpServer.java:4
    67)
    at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:404)
    at weblogic.j2ee.WebAppComponent.deploy(WebAppComponent.java:74)
    at weblogic.j2ee.Application.addComponent(Application.java:133)
    at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:327)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:143)
    at weblogic.management.mbeans.custom.WebServer.addWebDeployment(WebServe
    r.java:76)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy29.addWebDeployment(Unknown Source)
    at weblogic.management.configuration.WebServerMBean_CachingStub.addWebDe
    ployment(WebServerMBean_CachingStub.java:1012)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:313)
    at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(Depl
    oymentTarget.java:143)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBean
    s(ConfigurationMBeanImpl.java:409)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:287)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMB
    eanImpl.java:866)
    at weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMB
    eanImpl.java:853)
    at weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.ja
    va:838)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:566)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy14.addTarget(Unknown Source)
    at weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(Appli
    cationManager.java:486)
    at weblogic.management.mbeans.custom.ApplicationManager.addApplication(A
    pplicationManager.java:557)
    at weblogic.management.mbeans.custom.ApplicationManager.addApplication(A
    pplicationManager.java:504)
    at weblogic.management.mbeans.custom.ApplicationManager.poll(Application
    Manager.java:428)
    at weblogic.management.mbeans.custom.ApplicationManager.poll(Application
    Manager.java:380)
    at weblogic.management.mbeans.custom.ApplicationManager.update(Applicati
    onManager.java:152)
    at weblogic.management.mbeans.custom.ApplicationManager.startAdminManage
    r(ApplicationManager.java:205)
    at weblogic.management.mbeans.custom.ApplicationManager.start(Applicatio
    nManager.java:120)
    at java.lang.reflect.Method.invoke(Native Method)
    at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMB
    eanImpl.java:562)
    at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl
    java:548)
    at weblogic.management.internal.ConfigurationMBeanImpl.invoke(Configurat
    ionMBeanImpl.java:285)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    55)
    at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:15
    23)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
    at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
    at $Proxy3.start(Unknown Source)
    at weblogic.management.Admin.startApplicationManager(Admin.java:1037)
    at weblogic.management.Admin.finish(Admin.java:493)
    at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:429)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:170)
    at weblogic.Server.main(Server.java:35)

  • Error in precompiling JSPs using OJSPC

    Hi,
    I am precompiling JSPs in war file using ojspc as specified below.
         ojspc -output myapp.war app.war
    However I am getting following error:
    Detected archive, now processing contents of app.war...
    Setting up temp area...
    Expanding archive in temp area...
    WARNING: IGNORED file: /WEB-INF/lib/jsf-impl.jar
    WARNING: IGNORED file: /WEB-INF/lib/jsf-ri.jar
    Parse error in AddNewAttachment.jsp:
    oracle.jsp.parse.JspParseException: /AddNewAttachment.jsp: Line # 48,
    actionListener="#{addAttachmentBackingBean.cancel}"/>
    Error: A String literal value, "#{addAttachmentBackingBean.cancel}", has been pr
    ovided for attribute actionListener which has an associated deferred method with
    void signature
    Removing temp area...
    Can anbody help me to solve this problem?
    Thanks.
    Regards,
    Umesh

    Hi,
    If I create a method via the binding editor in JDev it creates a managed bean method with a void return type as default.
    eg.
        public void cmdlink_actionListener(ActionEvent actionEvent) {
            // Add event code here...
        }could it have anything to do with the two OJSPC warnings? jsf-impl.jar should be included in your war file. I haven't seen this warning when OJSPC is compiling.
    Brenden

  • Precompiled JSP Compatibility Problem

    I am a developer in the Cross Applications Unlimited group. We are experiencing a problem with precompiled jsps in a ADF web application that we have developed. Any help that you can provide with this problem would be much appreciated. Neither Oracle forums nor the internet have yielded any leads to us so far. Here are the specifics of our problem.
    In our application, we precompile our JSPs when the EAR is built. The application was initially developed in JDeveloper 10.1.3.2 and worked without problems when deployed to OAS 10.1.3.2. However, our application server MTR recently shifted to OAS 10.1.3.3. We migrated our workspace and projects to JDeveloper 10.1.3.3 and rebuilt our EAR file in JDeveloper 10.1.3.3. We are getting "500 Internal Server Errors" when this new ear file is deployed to OAS 10.1.3.3. The error does not always manifest when running the application. We can login and navigate to JSPs linked directly from our navigation menu (our first level pages). However, in these first level pages are buttons that navigate to second level pages. The error is being seen whenever we try to access one of these second level pages. Everything else about the application works fine. When we don't precompile our JSPs and deploy, the application works fine.
    This is the error we find reported in our application logs...
    EWCoreViewController: Servlet error
    javax.faces.el.PropertyNotFoundException: Error testing property 'inputValue' in bean of type null
    at com.sun.faces.el.PropertyResolverImpl.isReadOnly(PropertyResolverImpl.java:274)
    at oracle.adfinternal.view.faces.model.FacesPropertyResolver.isReadOnly(FacesPropertyResolver.java:124)
    at com.sun.faces.el.impl.ArraySuffix.isReadOnly(ArraySuffix.java:236)
    at com.sun.faces.el.impl.ComplexValue.isReadOnly(ComplexValue.java:209)
    at com.sun.faces.el.ValueBindingImpl.isReadOnly(ValueBindingImpl.java:266)
    Enabling enhanced java logging yields these logs...
    <record>
    <date>2008-04-09T11:27:25</date>
    <millis>1207762045495</millis>
    <sequence>258943</sequence>
    <logger>com.sun.faces.application.ViewHandlerImpl</logger>
    <level>FINE</level>
    <class>com.sun.faces.application.ViewHandlerImpl</class>
    <method>renderView</method>
    <thread>14</thread>
    <message>Found no URL patterns mapping to FacesServlet </message>
    </record>
    <record>
    <date>2008-04-09T11:27:25</date>
    <millis>1207762045495</millis>
    <sequence>258944</sequence>
    <logger>com.sun.faces.taglib.jsf_core.ViewTag</logger>
    <level>FINE</level>
    <class>com.sun.faces.taglib.jsf_core.ViewTag</class>
    <method>doStartTag</method>
    <thread>14</thread>
    <message>Can't leverage base class</message>
    <exception>
    <message>java.lang.IllegalStateException</message>
    <frame>
    <class>com.sun.faces.taglib.jsf_core.ViewTag</class>
    <method>getComponentType</method>
    <line>253</line>
    </frame>
    Any information anyone can provide would be greatly appreciated.
    Thanks

    Hi Ian,
    Add this jar file to classpath...use either web interface or directly edit jvm12.conf to modify classpath..
    Raj

  • Precompiling jsps Unexpected Signal : 11  JVM_IsInterface

              Hi,
              We have an weblogic 7.0 SP0 application running on solaris 7. As part of it startup
              in precompiles jsps - sometimes at different points weblogic crashes
              when we don't precompile the jsp's we never get this problem
              has any body seem it got a work around
              the message is
              Unexpected Signal : 11 occurred at PC=0xfe15b1c8
              Function name=JVM_IsInterface
              Library=/usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              Current Java thread:
              Dynamic libraries:
              0x10000      /usr/j2sdk1_3_1_03/bin/../bin/sparc/native_threads/java
              0xff360000      /usr/lib/libthread.so.1
              0xff3a0000      /usr/lib/libdl.so.1
              0xff280000      /usr/lib/libc.so.1
              0xff270000      /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
              0xfe000000      /usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              0xff210000      /usr/lib/libCrun.so.1
              0xff1f0000      /usr/lib/libsocket.so.1
              0xff100000      /usr/lib/libnsl.so.1
              0xff1c0000      /usr/lib/libm.so.1
              0xff240000      /usr/lib/libw.so.1
              0xff0e0000      /usr/lib/libmp.so.2
              0xff0a0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/native_threads/libhpi.so
              0xff070000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libverify.so
              0xff030000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libjava.so
              0xfe7d0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libzip.so
              0xfe650000      /usr/lib/nss_files.so.1
              0xfe540000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libnet.so
              0xfdee0000      /usr/lib/nss_nis.so.1
              0xfdec0000      /apps/wls70/weblogic/server/lib/solaris/libmuxer.so
              0xfdd50000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libioser12.so
              Local Time = Thu Sep 4 17:40:55 2003
              Elapsed Time = 288
              # HotSpot Virtual Machine Error : 11
              # Error ID : 4F530E43505002BD 01
              # Please report this error at
              # http://java.sun.com/cgi-bin/bugreport.cgi
              # Java VM: Java HotSpot(TM) Server VM (1.3.1_03-b03 mixed mode)
              Many thanks
              Malcolm Bridgeford
              

              See Sun's bug parade:
              http://developer.java.sun.com/developer/bugParade/bugs/4458653.html
              They fixed something in 1.3.1_04 that was causing errors similar to yours so you
              should probably try moving up to the _04 release.
              Also there are some know problems with older JVMs when JSPs get REALLY big through
              many custom tags, includes, etc. Breaks some internal 64K limit.. Might be related
              to that.
              -Greg
              Co-author of new advanced WebLogic book, "Mastering BEA WebLogic Server" http://www.amazon.com/exec/obidos/ASIN/047128128X
              "Malcolm Bridgeford" <[email protected]> wrote:
              >
              >Hi,
              >We have an weblogic 7.0 SP0 application running on solaris 7. As part
              >of it startup
              >in precompiles jsps - sometimes at different points weblogic crashes
              >
              >when we don't precompile the jsp's we never get this problem
              >
              >has any body seem it got a work around
              >
              >the message is
              >
              >Unexpected Signal : 11 occurred at PC=0xfe15b1c8
              >Function name=JVM_IsInterface
              >Library=/usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              >
              >Current Java thread:
              >
              >Dynamic libraries:
              >0x10000      /usr/j2sdk1_3_1_03/bin/../bin/sparc/native_threads/java
              >0xff360000      /usr/lib/libthread.so.1
              >0xff3a0000      /usr/lib/libdl.so.1
              >0xff280000      /usr/lib/libc.so.1
              >0xff270000      /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
              >0xfe000000      /usr/j2sdk1_3_1_03/jre/lib/sparc/server/libjvm.so
              >0xff210000      /usr/lib/libCrun.so.1
              >0xff1f0000      /usr/lib/libsocket.so.1
              >0xff100000      /usr/lib/libnsl.so.1
              >0xff1c0000      /usr/lib/libm.so.1
              >0xff240000      /usr/lib/libw.so.1
              >0xff0e0000      /usr/lib/libmp.so.2
              >0xff0a0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/native_threads/libhpi.so
              >0xff070000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libverify.so
              >0xff030000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libjava.so
              >0xfe7d0000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libzip.so
              >0xfe650000      /usr/lib/nss_files.so.1
              >0xfe540000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libnet.so
              >0xfdee0000      /usr/lib/nss_nis.so.1
              >0xfdec0000      /apps/wls70/weblogic/server/lib/solaris/libmuxer.so
              >0xfdd50000      /usr/j2sdk1_3_1_03/jre/lib/sparc/libioser12.so
              >
              >Local Time = Thu Sep 4 17:40:55 2003
              >Elapsed Time = 288
              >#
              ># HotSpot Virtual Machine Error : 11
              ># Error ID : 4F530E43505002BD 01
              ># Please report this error at
              ># http://java.sun.com/cgi-bin/bugreport.cgi
              >#
              ># Java VM: Java HotSpot(TM) Server VM (1.3.1_03-b03 mixed mode)
              >#
              >
              >Many thanks
              >Malcolm Bridgeford
              >
              >
              >
              

Maybe you are looking for