Precompiled JSP's in exploded deployment

We have several applications run in WLS 8.1 SP4 where we have chosen to precompile all JSP pages and package them in the WAR/EAR files. This
          has shortened the time of our deployment imensely, when we deploy the apps in archived format.
          However, we somethimes need to deploy the apps using an exploded format. The server compiles the JSP's even if we deliver an exact copy of what we have in our WAR/EAR-files. Having read postings of problems with this
          in previous versions of Weblogic, I'm curious to know if we are just doing things wrong, or if this is still an issue?
          Thankful for any information about this issue!
          Regards,
          /Eje Thorarinsson

Are you sure the timestamps on the JSP files are not modified by the build process?
If you compile the files into a destination dir say "bar/WEB-INF/classes" and then copy all the jsp files (w/o preserving the timestamps) to /bar which is then deployed. In this case all the JSPs will be recompiled since the class files contain the timestamp of the original JSP it was compiled against.
check out http://dev2dev.bea.com/pub/a/2005/01/jsp_reloaded.html which describes a bit about the jsp compilation process

Similar Messages

Precompile JSP for Application?

Hi,
i had been done the Examples in the NWDS(Help) and have some problems with them.
It isnt possible for me to deploy the war package to my mi without precompiled JSPs.
If i deploy them without precompiled JSPs i will get an exception like this:
Error: 500
Location: /TEST/initial.jsp
Internal Servlet Error:
javax.servlet.ServletException: sun/tools/javac/Main
I use MI 25 SP16 and NWDS Version 2.0.16.
Has anybody some ideas?
Thanx
Message was edited by: Tony Hennersdorf

Hi,
Doublecheck whether the environment variable JAVA_HOME is set, if not set it. Also check if path to jdk bin directory is added to the PATH variable of the user with which the j2ee engine is running.
Also check for javac.exe in winnt\System32 or any winnt subdirectories (if engine is running on Windows) if it is present remove it.
If all of above does not help, try changing the property of servlet_jsp service ExternalCompiler to the exact location of the javac executable on the system where the j2ee engine is running.
I hope this helps.
Myriana

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

Precompile JSPs before deployment

Does anyone have a working sample of precompiled JSPs distributed inside an EAR for deployment on an Oracle 10g app server?
I'm almost convinced it's impossible. Please prove me wrong.

I am glad to know that ojspc is indeed getting better.
Right, some ant file types can be helpful to provide list of files as argument to java command. Nice try!
For a while, I was down the road of using the batch mode against the ear but that is a
mess because it puts all the output in a "_pages" folder under the html root. I couldn't find
a way to change that behavior.This was changed in the next release 10.1.3, where the generated classes are put into a jar inside WEB-INF/lib/. The only way to get around it in 10.1.2 is to extract the ear/war file so that you will get a hold on the generated classes. Then you can put them in WEB-INF/lib or WEB-INF/classes and re-wrap the ear/war file.
It takes 8 minutes to compile 173 JSPs. I have an AMD 2200+ with 1GB RAM. You can use the "-verbose" option to feel how long each group of files got compiled. Does your jsp files have different encodings? Currently if a jsp file with each encoding is encountered, the java compiler used by ojspc will be recreated, which takes quite some time. Looking ahead, we are preparing to speed up the compile process by reusing the java compiler.
I'm not sure why ojspc can't do the directory recursion by itself.I will see if directory recursion should be implemented. Other options are also considered, like a deploy time option to compile all jsp artifacts. Do you think that would be a better option?
There also seems to be a bug in batch mode if ojspc is run from the Same directory as specified in the appRoot parameter.Can you give a bit more detail so that I can reproduce it? Thanks.
Try it out. Overall, it wasn't a very intuitive experience. Thanks for your feedback. I believe your experience will be getting better with each release.

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]

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

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

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

Using precompiled JSPs on Sun ONE 6.1 SP5

I"m using precompiled JSPs on Sun ONE 6.1 SP5. I have created a virtual server which has one web application deployed as the default web application located at <server-instance>/webapps/myapp. So in the server.xml it appears as :
<webapp uri="/" path="<server-instnce/webapps/myapp"
I have precompiled the JSPs using the jspc tool and created the directory containing the class files and have put them under WEB-INF/classes directory. I also generated the web.xml file with mappings for all jsps.
My problem is that in my web.xml I have specified the <welcome-file> as index.jsp which used to reside under the <server-instance>/webapps/myapp directory. but now since i'm using precompiled versions i have physically removed that file. And now when i point my browser to the app's URL in the browser, i get the app's directory structure and only when i explicitly point my browser to https://<ip>:port/index.jsp then only the index.jsp page is invoked. I'm confused with this behavior. Do I need to change my docsroot directory to point to where the jsp class files are stored? I dont know what else can be going wrong...
Any help appreciated :D
Thanks

Okkay i'll make my question easier.. if i'm using precompiled JSPs i.e. all compiled JSP files (.class files) including index.jsp is in the WEB-INF/classes directory then what is our docroot property supposed to be. Since if I give the document root as <server-instance>/webapps/myapp then it doesnt show the index.jsp that its supposed to when i point my browser to https://<host>:port. Only when I do https://<host>:port/index.jsp the index.jsp servlet is called and the index.jsp page is rendered.... I removed all the jsps physically from my apps folder but when I put only index.jsp there then it does work properly.... so any thoughts on this anyone...

How to set working-dir for precompiled jsp pages to some where under tmp

If my weblogic application gets exploded into this tmp directory:
D:\bea_domains\my_wl_domain\servers\SERVER001\tmp\_WL_user\mywebapp\wxyzzz\war
where "wxyzzz" is a random directory name generated by weblogic 9.2, how would I set my working-dir in weblogic.xml to store the precompiled jsp classes under:
D:\bea_domains\my_wl_domain\servers\SERVER001\tmp\_WL_user\mywebapp\wxyzzz\war\WEB-INF\classes\jsp_servlet\_jsp directory?
Is there an "expression" or "variable" that will hold the value of the tmp directory? Thanks.

If my weblogic application gets exploded into this tmp directory:
D:\bea_domains\my_wl_domain\servers\SERVER001\tmp\_WL_user\mywebapp\wxyzzz\war
where "wxyzzz" is a random directory name generated by weblogic 9.2, how would I set my working-dir in weblogic.xml to store the precompiled jsp classes under:
D:\bea_domains\my_wl_domain\servers\SERVER001\tmp\_WL_user\mywebapp\wxyzzz\war\WEB-INF\classes\jsp_servlet\_jsp directory?
Is there an "expression" or "variable" that will hold the value of the tmp directory? Thanks.

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

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!

Precompile jsp

Hi,
          do we need to specify any entry for precompiled jsp
          Thanks


To compile the JSPs during deployment, specify "precompile" as true in
          weblogic.xml
          To compile the JSPs during a build and deploy them without compiling them
          again, use the jspc tool with the -webapp option and put the classes in
          WEB-INF/classes
          HTH
          Alex
          On 25 Apr 2003 09:54:14 -0800, Mahesh <[email protected]> wrote:
          >Hi,
          >
          >do we need to specify any entry for precompiled jsp in web.xml
          >
          >Thanks

Precompile jsps via ant

I have a development project that has been setup to use JDeveloper 10.1.3.5.0 to create and EAR for deployment. The EAR is comprised of three sub applications - appData, appEjb, appWeb. Each subapplication has its own resource to deploy in JDeveloper. The appWeb has an additional resource defined in JDeveloper to deploy the EAR.
I am attempting to move the build process out of JDeveloper and into ant in order to integrate the application with an automated build management framework.
I have been successful in creating an ant build.xml to pull the code from source control, compile the three subapplications, jar the appData, and jar the appEjb. The issue I am having is precompiling the jsp files in the appWeb.
The JDeveloper resource for appWeb.deploy precompiles all the jsps and packages the jsp class files along with all the other appWeb content as part of the appWeb.war.
I thought JDeveloper was utilizing an internal J2EE standalone OC4J. I created a classpath and taskdef as follows
<path id="ojspc.classpath">
<fileset dir="jdevstudio">
<include name="**/*.jar"/>
</fileset>
<pathelement location="${env.JAVA_HOME}/lib/tools.jar" />
<pathelement location="${outDir}/appData"/>
<pathelement location="${outDir}/appWeb"/>
<pathelement location="${outDir}/appEjb"/>
</path>
<taskdef name="ojspc" classpathref="ojspc.classpath" classname="org.apache.tools.ant.taskdefs.optional.jsp.OjspC" />
My original attempts had a much more constrained classpath definition (using the classpath found in the manifest file within j2ee\home\ojspc.jar); however, ant is unable to find the OjspC class and thus I expanded the classpath to include all jar files.
After reading through blogs, forums, and documentation, I am unable to figure out how to define a task within ant to precompile the jsps in my project which mirrors the work being done via the JDeveloper deploy resource. Does anyone know the actual class to use for precompiling the jsps?
Any help is greatly apprciated,
/dclink

GR wrote:
          > Is there any ant task for precompiling jsp provided by weblogic 8.1.2?
          > (Ant's wljspc doesnt work with 8.1.2).
          Have you tired a regular java task that calls the class weblogic.jspc?
          A little more direct but I imagine it would work
          ~Ryan

Precompiled JSP files?

Hi,
I have precompiled my JSPs using the pre-compile option in the browser.(For
eg http://localhost:8080/Myapp/addCustomer.jsp?pre-compile)
I get the java and class files for each of the JSPs. These files are placed
in the work folder of Tomcat(ie
\jakarta-tomcat-5.0.16\work\Catalina\localhost\Myapp\org\apache\jsp).
If I want to deploy the web application as a WAR file (without the JSPs),
where should I place the .class files of the JSPs?
I have made entries in web.xml as shown below for each of the JSP files .
But , I get a 404 error when I try to access the
JSP(http://localhost:8080/Myapp/addCustomer.jsp).
<servlet>
<servlet-name>addCustomer_jsp</servlet-name>
<servlet-class>/Myapp/addCustomer_jsp</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>addCustomer_jsp</servlet-name>
<url-pattern>/Myapp/addCustomer.jsp</url-pattern>
</servlet-mapping>
It is not a must that I deploy it as a WAR file. But, where should I place
the precompiled JSPs so that I can access them from a browser? I am working
on Tomcat 5.
Thanks in advance.

Copy Jsps to install_dir/webapps/ROOT and access them with http://localhost/filename

Precompiled JSP's in exploded deployment

Similar Messages

Maybe you are looking for