Precompile JSP with useBean
"I am trying to precompile some of my jsps. When I try to precompile the JSP that uses useBean. I got the following error: Exception in thread "main" java.lang.ExceptionInInitializerError:
Shanna Chan <[email protected]> wrote:
>"I am trying to precompile some of my jsps. When I try to precompile the
>JSP that uses useBean. I got the following error: Exception in thread "main"
>java.lang.ExceptionInInitializerError:
I hit this problem a lot too. On investigation, it's always because I forget that
with jspc, there are
*two* classpaths: the one you call weblogic.jspc with, and the one you pass to javac
with the -classpath option.
You need your bean classes in both, as the jsp-java parser instantiates beans before
generating (I guess
as a validity check).
Similar Messages
-
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
>>
>>
>>
>
>
-
Tomcat5 and precompiling JSPs with Ant
Hi I'm trying to precompile my JSPs in ANT and I'm using Tomcat5. Below is my taskdef:
<target name="jsp" depends="build">
<!--
The Ant JSPC task doesn't work with Tomcat 5.0
so in the meantime we need to define our own task.
-->
<taskdef name="jspc50" classname="org.apache.jasper.JspC">
<classpath id="jspc50.classpath">
<fileset dir="${tomcat.home}">
<include name="*.jar"/>
</fileset>
</classpath>
</taskdef>
<jspc50 outputDir="${classes}"
uriroot="${src}"
package="jsp"
validateXml="false">
<include name="**/*.jsp" />
<exclude name="**/includes/**/*.jsp" />
</jspc50>
<javac srcdir="${classes}"
destdir="${classes}"
debug="true"
optimize="false"
includes="**/*.java"
source="1.4">
</javac>
</target>Now, this actually works but if I use an absolute include directive in my JSPs like:
<%@ include file="/includes/header.jsp" %>Then I get the "/include/header.jsp" not found. However, if I change to
<jsp:include page="/includes/header.jsp" />It works fine. Now, I want to use an absolute path and I also want to use the include directive. Has anybody seen this problem and know a solution?
Thanks,
MikeHi All,
Pls. help
I have deployed my application on Sun Appln server 9.0. When I try to lauch the application it gives following error.
[#|2007-11-06T17:31:16.451+0530|SEVERE|sun-appserver-pe9.0|javax.enterprise.system.container.web|_Th
readID=13;_ThreadName=httpWorkerThread-8080-0;_RequestID=076de172-4f31-4f76-888d-a19cc736c3ee;|Stand
ardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.NoClassDefFoundError: javax/servlet/jsp/tagext/TagExtraInfo
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:100)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:176)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1405)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1292)
at org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryInfoImpl.java:478)
at org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:298)
at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:176)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:445)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:513)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1579)
at org.apache.jasper.compiler.Parser.parse(Parser.java:151)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:212)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:129)
at org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:360)
at org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:397)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:505)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1579)
at org.apache.jasper.compiler.Parser.parse(Parser.java:151)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:212)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:113)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:224)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:526)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:507)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:495)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:530)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:412)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.jav
a:397)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at com.fdu.mdsgui.web.filter.LocaleFilter.doFilter(LocaleFilter.java:58)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
at com.fdu.mdsgui.web.filter.MDSSecurityFilter.doFilter(MDSSecurityFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:216)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:184)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:24
0)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:6
67)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.ja
va:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
|#] -
Precompiling JSPs with taglib dependency
Hi, all.
Could someone tell me how to specify taglib for jspc ?
Whenever I try to precompile my JSPs, the ones that have dependency upon
taglib always fail with the following message:
java.lang.NullPointerException at
weblogic.servlet.jsp.JspLexer.getHomeRelativeFile(JspLexer.java:59) at
weblogic.servlet.jsp.JspLexer.isWebLogicTagLib(JspLexer.java, Compiled
Code) at
weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:69) at
weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java,
Compiled Code)
at
weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java, Compiled
Code) at
weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java, Compiled Code)
at
weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1677) at
weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1518) at
weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java, Compiled Code) at
weblogic.servlet.jsp.JspLexer.parse(JspLexer.java, Compiled Code) at
weblogic.servlet.jsp.JspParser.doit(JspParser.java, Compiled Code) at
weblogic.servlet.jsp.JspParser.parse(JspParser.java:116) at
weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97) at
weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java,
Compiled Code) at
weblogic.jspc.runBody(jspc.java,
Compiled Code) at
weblogic.utils.compiler.Tool.run(Tool.java:80) at
weblogic.jspc.main(jspc.java:111)
I'm using WL5.1 with SP5.
TIA,
Kim.
Yep, this is a known issue.
Work is in progress.
Kumar
Kim Kofman wrote:
>
> Hi, all.
> Could someone tell me how to specify taglib for jspc ?
> Whenever I try to precompile my JSPs, the ones that have dependency upon
> taglib always fail with the following message:
> java.lang.NullPointerException at
>
> weblogic.servlet.jsp.JspLexer.getHomeRelativeFile(JspLexer.java:59) at
>
> weblogic.servlet.jsp.JspLexer.isWebLogicTagLib(JspLexer.java, Compiled
> Code) at
>
> weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:69) at
>
> weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java,
> Compiled Code)
> at
> weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java, Compiled
> Code) at
>
> weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java, Compiled Code)
> at
>
> weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1677) at
>
> weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1518) at
>
> weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java, Compiled Code) at
>
> weblogic.servlet.jsp.JspLexer.parse(JspLexer.java, Compiled Code) at
>
> weblogic.servlet.jsp.JspParser.doit(JspParser.java, Compiled Code) at
>
> weblogic.servlet.jsp.JspParser.parse(JspParser.java:116) at
>
> weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97) at
>
> weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java,
> Compiled Code) at
> weblogic.jspc.runBody(jspc.java,
> Compiled Code) at
>
> weblogic.utils.compiler.Tool.run(Tool.java:80) at
> weblogic.jspc.main(jspc.java:111)
>
> I'm using WL5.1 with SP5.
>
> TIA,
> Kim.
-
JSP with useBean beginner problems need help
I start to learn JSP and now I am facing a problem which cannot be solved for a whole day.
I make a simple JSP and want to use a my defined class to make some logic outside JSP file. It can be built by "ant build".
But there is always an error-message when I see through browser. Also, I have already "ant deploy" to copy all classes in WEB-INF/classes/...
Besides, my tomcat can run JSP without importing external class or javaBean.
Please help. I really have no idea. Thanks.
The simple Converter.class in Test.Beans package
package Test.Beans;
import java.math.*;
public class Converter {
static BigDecimal yenRate = new BigDecimal("131.7800");
static BigDecimal euroRate = new BigDecimal("0.0084");
public BigDecimal dollarToYen(BigDecimal dollars) {
BigDecimal result = dollars.multiply(yenRate);
return result.setScale(2,BigDecimal.ROUND_UP);
public BigDecimal yenToEuro(BigDecimal yen) {
BigDecimal result = yen.multiply(euroRate);
return result.setScale(2,BigDecimal.ROUND_UP);
public Converter() {}
The simple JSP:
<%@ page import="java.math.*" %>
<jsp:useBean id="c" class="Test.Beans.Converter" scope="page"/>
<html>
<head>
<title>Converter</title>
</head>
<body bgcolor="white">
<FONT SIZE=+1>
<h1><center>Converter</center></h1>
<hr>
<p>Enter an amount to convert:</p>
<form method="get">
<input type="text" name="amount" size="25">
<br>
<p>
<input type="submit" value="Submit">
<input type="reset" value="Reset">
</form>
<%
String amount = request.getParameter("amount");
if ( amount != null && amount.length() > 0 ) {
BigDecimal d = new BigDecimal (amount);
%>
<%= c.yenToEuro(d) %> Euro.
<%
%>
</FONT>
</body>
</html>
Here is the error message:
org.apache.jasper.JasperException: /main.jsp(2,0) The value for the useBean class attribute Test.Beans.Converter is invalid.
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
root cause
org.apache.jasper.JasperException: /main.jsp(2,0) The value for the useBean class attribute Test.Beans.Converter is invalid.
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:405)
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:146)
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1174)
org.apache.jasper.compiler.Node$UseBean.accept(Node.java:1116)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2213)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2219)
org.apache.jasper.compiler.Node$Root.accept(Node.java:456)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
org.apache.jasper.compiler.Generator.generate(Generator.java:3304)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:198)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:295)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
Message was edited by:
BillyHuiWorks fine for me, copied and pasted exactly.
Try recompiling your java class again, to make sure it is valid.
Check that the class file is copied into the correct place by your ant build.
Should be WEB-INF/classes/Test/Beans/Converter.class -
Example with :useBean failed !
Hi all,
I don't know how to run (compilation & deployment) a .jsp with
:useBean.
My question is : where I have to place the .class of the JavaBean in
order that a Web Server (Tomcat (C:\jakarta-tomcat-4.0.4) or
Weblogic Server 7.0) can run my .jsp ?
Description :
+ My 1rst file .jsp is :
<html> <head> <TITLE> test</TITLE></head>
<body>
<jsp:useBean id="myTest" class="Bean1_4" />
</body> <html>
+ My 2nd file .java contains the code for the JavaBean :
public class Bean1_4 {
private String message = "No ";
public String getMessage() {return message; }
public void setMessage(String message) {this.message = message; }
+ I compiled the C:\jdk1.3\bin\Bean1_4.java :
C:\jdk1.3\bin\javac -d . Bean1_4.java <ENTER>
-> Compilation is OK. Then we have : C:\jdk1.3\bin\Bean1_4.class
+ To run the .jsp, I do this :
- I copied the target .jsp into the Tomcat directory :
C:\jakarta-tomcat-4.0.4\webapps\ROOT\test1_4.jsp
- I copied the .class of the bean in :
C:\jakarta-tomcat-4.0.4\webapps\ROOT\WEB-INF\classes\Bean1_4.class
or(?) in C:\jakarta-tomcat-4.0.4\classes\Bean1_4.class
- I launched the Tomcat server :
(C:\jakarta-tomcat-4.0.4\bin\startup.bat <ENTER>)
- I launched Internet Explorer 5.0 with the URL :
http://localhost:8080/test1_4B.jsp
There are ERRORS ! Why ? Can you help me ?
+ Conclusion :
- Can you help me to run this simple example ?
- I think that the jsp compiler doesn't know where to find the
.class. So, there are errors ! In this case, where (in which
directory) et how (CLASSPATH ?) can I modify to run this example?
ThanksBeans belong in the web-inf/classes dir.
Do not forget to add a package, bug in tomcat, I think, by adding (in top of bean):
package test;
The .class should then be placed in the web-inf/classes/test dir, change the .jsp to:
<jsp:useBean id="myTest" class="test.Bean1_4" scope="page"/>
<html> <head> <TITLE> test</TITLE></head>
<body>
<jsp:getProperty name="myTest" property="message"/>
</body> <html> Please notify that "scope" and "package" have been added.
Andreas -
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 -
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,
UmeshHi,
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 -
Pre-compiled JSPs with main_mode = recompile
I would like to precompile JSPs and allow changes to be recompiled after an application has been deployed. In other words, I want to use ojspc to precompile my JSPs and set main_mode to recompile in web.xml. In such a scenario, I would like changes to JSPs in the web folder to be reflected. Otherwise, it should just take the precompiled JSP. Does anyone know if that is possible?
I have tried it out and this is what I have found. If I set main_mode to recompile in the web.xml and include the jar of precompiled JSPs in the WEB-INF/lib folder then it never recompiles any changes to JSPs in the web application. Is that the way it is supposed to behave or should it be recompiling the changed JSP?Yes it is possible to do this; you can package up the classes and WebLogic will
attempt to load them - if the class load works, no recompile is needed.
But there's a bug in weblogic.servlet.jsp.Precompiler.java - it's looking for
a classname with a single leading underscore (e.g. myjsp.class), but ejbc outputs
classes with a double leading underscore (e.g. __my_jsp.class).
I've done a patch for Precompiler.java, and now it all works as it ought to.
simon.
-
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.
ThanksHi Ian,
Add this jar file to classpath...use either web interface or directly edit jvm12.conf to modify classpath..
Raj -
Precompile JSP's in Weblogic 5.1/SP6
Hello,
How do you get the precomplilation of JSP's to work in 5.1? I have
seen some emails on this mailing list about how to precompile the
JSP's in 6.0 but I would like to know how to do it in 5.1. looking
at the documentation here: http://www.weblogic.com/docs51/classdocs/API_jsp.html#register
In the weblogic properties file we have them set as follows:
weblogic.httpd.documentRoot=htdocs/
# WEBLOGIC JSP PROPERTIES
# Sets up automatic page compilation for JSP. Adjust init argsfor
# directory locations and uncomment to use.
weblogic.httpd.register.*.jsp=weblogic.servlet.JSPServlet
weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=1,\
keepgenerated=true,\
compileCommand=d:/jdk1.2.2/bin/javac.exe,\
workingDir=D:/Mediaprise/mpsite/WebLogicServer,\
verbose=true
that should be picking up any JSP's underneath the document root
folder (htdocs, in this case) and precompile them to the working
dir. now we have JSP's in the htdocs folder and a whole stucture
of JSP's underneath the htdocs folder in a folder called JSP with
it's own file and directory structure. The weblogic.log file shows
that the above properties are being set correctly on startup but
no precompilation seems to be happening to the working dir. any
ideas on how to make this work in 5.1??
I am working on Weblogic 5.1 with SP6.
Thanks,
Gagan
In WebLogic 6.0 register each jsp in the web.xml with a <servlet-name>, <jsp-file>
and <load-on-startup>. For example:
<web-app>
<servlet>
<servlet-name></servlet-name>
<jsp-file></jsp-file>
<load-on-startup></load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name></servlet-name>
<url-pattern></url-pattern>
</servlet-mapping>
</web-app>
The optional value of load-on-startup element must be a positive integer indicating
the order in which the servlet should be loaded.
In WebLogic 6.1 set the precompile parameter in weblogic.xml.
<jsp-descriptor>
<jsp-param>
<param-name>
precompile
</param-name>
<param-value>
true
</param-value>
</jsp-param>
</jsp-descriptor>
Vaibhav wrote:
> This solution is with web.xml, if I am
> using weblogic.properties only and no web.xml, How do I specify precompile=true ?
-
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
>
>
>
-
Precompiling JSPs changes directory name
I am using the weblogic.appc compiler to precompile JSPs and I noticed that if my source folder name contains a hyphen, eg. my-test, after precompilation the class files are stored under \WEB-INF\classes\jsp_servlet\_my_45_test\ directory.
The "-" in the name is substituted by its ASCII value. Is there a way to stop this from happening other than choosing a different name for the source folder?
Thankscranestar wrote:
Oracle db versesion : 11g
Apex version: 4.1.0.00.32
I have created a file browse object on a page. After filling several text boxes and selecting a file the page writes a row into a table
in the database.
When a file is selected with the file browse the name looks like:
C:\OracleApex\PDM-BOM comparison app\datafiles\B-15680-49_D_SAP.CSV
However in the database the name appears as:
F1531709975/B-15680-49_D_SAP.CSV
What happened to the directory name? This causes problems because I need to use the directory and file name in a utl_file
utility.<tt>F1531709975</tt> is produced to provide a unique file identifier in the <tt>apex_application_files</tt> view, and is the session state value of the file browse control that uploaded the file. The actual filename is available in the <tt>filename</tt> column.
As has been noted in many previous threads on this topic: For security/privacy reasons recent versions of browsers by default do not send local file path information from File Browse items to the server, nor expose the file path in the control's JavaScript methods. Firefox, Safari and Chrome only provide the filename. IE6 & IE7 still yield the path in Windows format. IE8+ and Opera have adopted an irritating approach of replacing the path with a wholly imaginary "C:\fakepath\"—and this monstrosity has sadly had to be enshrined in the HTML5 spec...
Changing IE's security config setting "Include local directory path when uploading files" enables the path to be exposed in IE, but unless you're working in an intranet environment where: IE is the only browser used; it's possible to make remote changes to this setting on every desktop; and this won't break/expose anything else, then trying to achieve this is pointless.
For more information see:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018980.html
http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
http://developers.whatwg.org/number-state.html#file-upload-state -
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 AMI 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?
Maybe you are looking for
-
How to prevent a problen in ONE TAB from hanging ALL FIREFOX ?
The problem is that a problem causing a hang in one tab can hangup all of firefox so I can't do anything. For example, an unresponsive script invoked by one tab (one website) causes all of firefox to stop running., and I can't use the mouse or keyboa
-
OBIEE 11G - SQL filter Injection
will it be possible to SQL inject a dynamic filter at the RPD level? I was thinking of doing in the WHERE clause on the CONTENT tab of the Logical Table Source but then I'm not allowed to. The filter I want to apply is AS OF TIMESTAMP to_timestamp(<v
-
What is the meanning of volume 1
hi , i saw an instructor guide ( a book ) , written in it volume 1 and i saw too volume 2 , are they the same but 2 is another edition , or volume 1 for begginers and 2 contains an advanced topics ? i do not mean in a certain field of oracle , i mean
-
WMV not visible in Finder after clean install
I just got a new HD and re-installed all my softawre. QT opens everything, but Finder can't preview the files and gives me that spinning ( not beach ball ) loading icon. Should I just re-install QT+all related software? Paul
-
No changes in TU report, but changes in TU scores...
So I took a drop across the board on TU today.FICO 08 743->739FICO 04 713->711FICO AUTO 8 764->758FICO AUTO 4 733->731FICO BANKCARD 8 758->754FICO BANKCARD 4 719->717Not a big drop, but