Compiler JSP with comment

Hi,
I want the comment ine the source Java while the line number of JSP page.
I use Jasper for compiling the JSP pages.
Why the compiler Jspc > v4.0 don't add this comment in the source code JAVA ?
It is possible add this comment in the source ? with option (command line or call java) or do you know an another compiler free which add this comment.
Thanks !

I'm not exactly sure what you want to do, but it sound like you just want a comment in your jsp to show up in the generated source file.
There are 3 kinds of comments you can use in your jsp. Firstly you have jsp comments (<%-- ... --%>) which only shows in the jsp. Secondly you have java comments (<% // ... %> or <% /* ... */ %>) which will show in the jsp and the generated source. And lastly you have html comments (<!-- ... -->) which will show in the jsp, source, and the response to the client.
Hope this helps.

Similar Messages

  • Compiled JSPs With Jasper - Now Includes don't work

    I am using a template page (index.jsp) that includes other jsp pages to fill the body of the page. Previously, I had my index.jsp page as the root document and the other jsp's in a 'jsp' subfolder. To include the other jsp's, I was using hyperlinks like this:
    where 'XXXX' is the name of the jsp page without the '.jsp' extension.
    So, in the index.jsp page, I had the following line of code that included the jsp pages:
    <%
    pageContext.include("/jsp/" + include + ".jsp"); // include is the 'page' request parameter.
    %>
    This has worked flawlessly up to this point. However, now I want to precompile all JSP pages using Ant and Jasper as this is a distributed app and I don't want to ship jsp pages. I compiled the pages and updated the web.xml file with the new mappings. Now the index.jsp page (servlet) displays but does not include the compiled jsp pages. Will the same link to a jsp page use the servlet mappings in the web.xml file to map to the new servlet?
    I also tried the following with the same result:
    request.getRequestDispatcher("/jsp/" + include + ".jsp").include(request,response);
    Can someone suggest a solution? How can I get the compiled jsp's (servlets) to be included and displayed in the same way they were when used as jsp pages?

    Well, good news and bad news....
    I got the includes to work by changing my index.jsp page to use the following:
    <jsp:include page="<%=includePage%>" flush="true"/>
    instead of:
    pageContext.include("/jsp/" + include + ".jsp");
    This seems to work.
    However, this has uncovered another issue. Now none of the graphics for the page display. So I am left with a page that has broken images links all over it. Does anyone know how to get around this? All my links follow the format:
    <img src="/images/...
    so they should resolve to the base directory, then 'images' right? When I look at the properties for each broken image, they have the correct path... does anyone know why they wouldn't display? What do I need to do to allow the servlets to display the images properly like the jsp pages did?
    Thanks in advance...

  • Compiling jsp with tomcat 4

    HTTP 500 server error as follows:
    org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated.
    An error occurred at line: 2 in the jsp file: /listStore.jsp
    *line#2 is the usebean statement in the jsp...
    NOTE: new machine, new configuration... this same servelt/jsp/bean work great on another machine with tomcat 3...
    so this will have something to do with tomcat configuation... believe that the configuration is set to not compile with deprecation.. would like to know where to change that...

    I guess the problem comes from jdk 1.4 ...deprecation of sun.tools.javac.Main prevents compilation in jasper...

  • Compiling JSPs with -g

    Hello,
              how can I get WLS to compile my JSPs (deployed in a .war-file) with
              debugging info (i.e. the javac "-g" Flag)? I tried to set the
              "compileCommand" property in weblogic.properties, but it's being
              ignored. Here's what I did:
              weblogic.httpd.initArgs.*.jsp=\
              pageCheckSeconds=1,\
              compileCommand=/path/to/wls/javacg.sh,\
              workingDir=/path/to/wls/myserver/classfiles,\
              verbose=true
              javacg.sh is a shell script that calls javac with the -g flag, like
              this:
              #!/bin/sh
              javac -g $*
              I also tried to set the "compileCommand" to "javac -g" directly.
              But on startup, WLS keeps telling me that:
              <WebAppServletContext-appcontext> *.jsp: param compileCommand initialized to: javac
              The string "javac" doesn't appear anywhere in weblogic.properties
              except for the abovementioned property definition.
              Do the above properties apply to JSPs deployed in WAR-files at all? If
              not, where can I set them?
              I also tried to compile my JSPs manually with weblogic.jspc -g , but
              WLS would always re-compile the JSPs upon their first invocation.
              Any hints?
              TIA,
              Olaf
              Olaf Klischat | Fraunhofer ISST
              Oberfeldstrasse 132 | Mollstrasse 1
              12683 Berlin, Germany | 10178 Berlin, Germany
              phone: +49 30 54986231 | mail: [email protected]
              

    Hi,
              I think that for web applications (i.e. war files) the options to the
              JSP servlet (which is the one doing the compilation) must be in the
              web.xml file (deployment descriptor). Most options in the
              weblogic.properties file do not apply for a war file, they have to be
              specified in the web.xml.
              Mathieu
              Olaf Klischat wrote:
              >
              > Hello,
              >
              > how can I get WLS to compile my JSPs (deployed in a .war-file) with
              > debugging info (i.e. the javac "-g" Flag)? I tried to set the
              > "compileCommand" property in weblogic.properties, but it's being
              > ignored. Here's what I did:
              >
              > weblogic.httpd.initArgs.*.jsp=\
              > pageCheckSeconds=1,\
              > compileCommand=/path/to/wls/javacg.sh,\
              > workingDir=/path/to/wls/myserver/classfiles,\
              > verbose=true
              >
              > javacg.sh is a shell script that calls javac with the -g flag, like
              > this:
              >
              > #!/bin/sh
              >
              > javac -g $*
              >
              > I also tried to set the "compileCommand" to "javac -g" directly.
              >
              > But on startup, WLS keeps telling me that:
              >
              > <WebAppServletContext-appcontext> *.jsp: param compileCommand initialized to: javac
              >
              > The string "javac" doesn't appear anywhere in weblogic.properties
              > except for the abovementioned property definition.
              >
              > Do the above properties apply to JSPs deployed in WAR-files at all? If
              > not, where can I set them?
              >
              > I also tried to compile my JSPs manually with weblogic.jspc -g , but
              > WLS would always re-compile the JSPs upon their first invocation.
              >
              > Any hints?
              >
              > TIA,
              > Olaf
              > --
              > Olaf Klischat | Fraunhofer ISST
              > Oberfeldstrasse 132 | Mollstrasse 1
              > 12683 Berlin, Germany | 10178 Berlin, Germany
              > phone: +49 30 54986231 | mail: [email protected]
              

  • Can't compile JSPs with Forte 4

    I upgraded to forte 4 CE. Now I cannot compile my JSP's because they are not finding my class files.
    They all worked in Forte 3 ce.
    If I have class MyClass()
    and try to create an instance in my JSP
    MyClass mc = new MyClass()
    It gives the 'cannot resolve symbol' error on MyClass object.
    What happened? I haven't changed anything. I have about 10 jsps and a bunch of Classes that all worked and now don't.
    I checked the product support for Forte and couldn't find anything.
    If anybody else had this problem and figured it out please post your solution.
    Thanks.
    -chiranjp

    i am having the same problem using my "homemade" class with forte.
    I have all of the .java and .class files and even have a .jar file but it still cannot find them
    could you please give me more details on how you reached your solution?
    where did you place the files so that forte found them?
    any and all help is greatly appreciated.
    thanks
    -j

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

  • Register 12 VerifyError exception when compiling jsp with that jsp tag!

              Hi everybody,
              We implemented a tag which is charged with a simple task like just "out.println"s,
              on production with WL5.1 SP11,jdk1.2.
              Then we got java.lang.VerifyError exception which is also denoted at Giuseppe Madonna's
              mail on ( http://newsgroups2.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.jsp&item=6834&utag=
              ) that "java.lang.VerifyError: Register 12 contains wrong type"
              To be able to find the inconsistency in class files denoted at VerifyError exception,
              we delete the tmp dir. of web app resides in a war.
              Also the related java beans used in jsp tag and related jsp, are in a jar on our
              classpath and .tld file resides in the .war file of our web application.
              But also, I must define that it is our first tag implemented after we migrate to
              the .war file after the web application directory structure of same application(that
              old dir. also deleted), I know it is silly but, is it possible that WL can now refer
              to something related our previous directory structure of our app. like that old .tld
              file or classes?
              Or may it be related with the difference between jdk versions on the test and the
              production server?
              Any help will be really appreciated..
              Many thanks,
              Banu
              

              Start up weblogic with -
              java -noverify ....
              Mike
              "banu" <[email protected]> wrote:
              >
              >Hi everybody,
              >We implemented a tag which is charged with a simple task like just "out.println"s,
              >on production with WL5.1 SP11,jdk1.2.
              >
              >Then we got java.lang.VerifyError exception which is also denoted at Giuseppe
              >Madonna's
              >mail on ( http://newsgroups2.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.jsp&item=6834&utag=
              >) that "java.lang.VerifyError: Register 12 contains wrong type"
              >
              >To be able to find the inconsistency in class files denoted at VerifyError
              >exception,
              >we delete the tmp dir. of web app resides in a war.
              >
              >Also the related java beans used in jsp tag and related jsp, are in a jar
              >on our
              >classpath and .tld file resides in the .war file of our web application.
              >
              >But also, I must define that it is our first tag implemented after we migrate
              >to
              >the .war file after the web application directory structure of same application(that
              >old dir. also deleted), I know it is silly but, is it possible that WL can
              >now refer
              >to something related our previous directory structure of our app. like that
              >old .tld
              >file or classes?
              >
              >Or may it be related with the difference between jdk versions on the test
              >and the
              >production server?
              >
              >
              >Any help will be really appreciated..
              >Many thanks,
              >Banu
              >
              

  • "No tag library could be found with this URI" error while compiling jsp

    I am using WebLogic Server 9.2 MP1, JDK 1.5.0_09, Struts 1.3.5
              I am pre-compiling jsp pages with wlappc ant task. However, I got following errors when a jsp page contains ant taglib:
              No tag library could be found with this URI. Possible causes could be that the URI is incorrect, or that there were errors during parsing of the .tld file.
              The jsp page looks like:
              <%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %>
              wlappc complains taglib could not be retrieved from this uri. Actually, since Struts 1.3.5, those ".tld" files are contained in strust-taglib-1.3.5.jar, folder META-INF/tld/. And I don't need to set anything in web.xml <tag-lib> tab anymore.
              All the jsp pages can be successfully compiled while being deployed to Server. So what am I missing? My build.xml file looks like:
                   <target name="compile-jsp">
                        <wlappc source="${src.dir}" output="${out.dir}"
                             keepgenerated="true" optimize="true" classpathref="wl_classpath"/>
                   </target>
              where "wl_classpath" contains all the struts related jar files, e.g. struts-core-1.3.5.jar, struts-taglib-1.3.5.jar, ...., and weblogic related jars, e.g. weblogic.jar.....
              I checked "beehive" samples coming with weblogic92, and found it pretty much did the same thing regarding build script and jsp files. So I am totally lost!
              Please help me out. Many thanks.
              Edited by jqian at 02/02/2007 10:24 AM

    Yes sorry, you're correct. The uri I mentioned is just 1.0.
    Do you have the "Oracle WebLogic Web App Extension" Facet for your web project? If not, try adding that and making sure that there is a weblogic.xml file created in the WEB-INF dir. The weblogic.xml file allows you to deploy usig a shared lib for JSTL. It should contain a library-ref element something like the following, with a version of 1.1.
    <wls:library-ref>
    <wls:library-name>jstl</wls:library-name>
    <wls:specification-version>1.1</wls:specification-version>
    <wls:exact-match>true</wls:exact-match>
    </wls:library-ref>

  • Problem with BPM workspace - Failed to compile JSP /bpmHome.jsff

    Hi
    I have instaled SOA Suite 11gR1 (11.1.1.5.0). All console woks, except bpm workspace. I have following error after login
    Incident Id: 3
    Incident Source: SYSTEM
    Create Time: Thu Sep 22 09:21:36 CEST 2011
    Problem Key: BEA-101017 [HTTP][weblogic.servlet.jsp.CompilationException]
    Application Name: OracleBPMWorkspace
    Error Message Id: BEA-101017
    Description
    Incident detected using watch rule "UncheckedException":
    Watch time:             2011-09-22 09:21:36 CEST
    Watch ServerName:       soa_server1
    Watch RuleType:         Log
    Watch Rule:             (SEVERITY = 'Error') AND ((MSGID = 'WL-101020') OR (MSGID = 'WL-101017') OR (MSGID = 'WL-000802') OR (MSGID = 'BEA-101020') OR (MSGID = 'BEA-101017') OR (MSGID = 'BEA-000802'))
    Watch DomainName:       SOADomain
    Watch Data:
       DATE : 2011-09-22 09:21:36 CEST
       SERVER : soa_server1
       MESSAGE : [ServletContext@9413464[app:OracleBPMWorkspace module:/bpm/workspace path:/bpm/workspace spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@31c41d[
    GET /bpm/workspace/faces/jsf/worklist/worklist.jspx?_afrLoop=4649677285821&_afrWindowMode=0&_adf.ctrl-state=7b5s8pm1s_4 HTTP/1.1
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.13) Gecko/20101209 CentOS/3.6-2.el5.centos Firefox/3.6.13
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: pl,en-us;q=0.7,en;q=0.3
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 115
    Connection: keep-alive
    Referer: http://localhost:8001/bpm/workspace/faces/jsf/worklist/worklist.jspx
    Cookie: JSESSIONID=XS3VT6hZBFLPZvqGZsnjQWnhgG06NTnDHMX9QY8Wbf1FvBZ4QYTK!-276213214
    ]] Root cause of ServletException.
    weblogic.servlet.jsp.CompilationException: Failed to compile JSP /bpmHome.jsff
    Exception occurred while processing '/home/kuba/Oracle/Middleware/user_projects/domains/SOADomain/servers/soa_server1/tmp/_WL_user/OracleBPMWorkspace/jx2oeu/war/bpmHome.jsff'java.lang.NullPointerException
         at weblogic.jsp.internal.jsp.JspParser.jspParse(JspParser.java:1092)
         at weblogic.jsp.internal.jsp.JspParser._parse(JspParser.java:604)
         at weblogic.jsp.internal.jsp.JspParser.parse(JspParser.java:597)
         at weblogic.jsp.internal.jsp.JspAnalyzer.parseFile(JspAnalyzer.java:104)
         at weblogic.jsp.internal.jsp.JspAnalyzer.parse(JspAnalyzer.java:92)
         at weblogic.jsp.internal.ProxySourceFile.parse(ProxySourceFile.java:106)
         at weblogic.jsp.internal.SourceFile.getAst(SourceFile.java:559)
         at weblogic.jsp.internal.SourceFile.getAst(SourceFile.java:533)
         at weblogic.jsp.internal.SourceFile.check(SourceFile.java:335)
         at weblogic.jsp.internal.ProxySourceFile.codeGen(ProxySourceFile.java:224)
         at weblogic.jsp.internal.SourceFile.codeGen(SourceFile.java:327)
         at weblogic.jsp.internal.client.ClientUtilsImpl$CodeGenJob.run(ClientUtilsImpl.java:599)
         at weblogic.jsp.internal.client.Job.performJob(Job.java:83)
         at weblogic.jsp.internal.client.ThreadPool$WorkerThread.run(ThreadPool.java:217)
         at weblogic.servlet.jsp.JavelinxJSPStub.reportCompilationErrorIfNeccessary(JavelinxJSPStub.java:226)
         at weblogic.servlet.jsp.JavelinxJSPStub.compilePage(JavelinxJSPStub.java:162)
         at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:256)
         at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:216)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:243)
         at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:416)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:326)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
         at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:523)
         at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:444)
         at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:163)
         at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:184)
         at oracle.adfinternal.view.faces.taglib.region.IncludeTag.__include(IncludeTag.java:442)
         at oracle.adfinternal.view.faces.taglib.region.RegionTag$1.call(RegionTag.java:153)
         at oracle.adfinternal.view.faces.taglib.region.RegionTag$1.call(RegionTag.java:128)
         at oracle.adf.view.rich.component.fragment.UIXRegion.processRegion(UIXRegion.java:503)
         at oracle.adfinternal.view.faces.taglib.region.RegionTag.doStartTag(RegionTag.java:127)
         at jsp_servlet._jsf._worklist.__worklist_jspx._jspx___tag27(__worklist_jspx.java:1265)
         at jsp_servlet._jsf._worklist.__worklist_jspx._jspx___tag26(__worklist_jspx.java:1232)
         at jsp_servlet._jsf._worklist.__worklist_jspx._jspx___tag14(__worklist_jspx.java:723)
         at jsp_servlet._jsf._worklist.__worklist_jspx._jspx___tag13(__worklist_jspx.java:673)
         at jsp_servlet._jsf._worklist.__worklist_jspx._jspService(__worklist_jspx.java:168)
         at weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:175)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:524)
         at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:253)
         at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:410)
         at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
         at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
         at oracle.adfinternal.view.faces.config.rich.RecordRequestAttributesDuringDispatch.dispatch(RecordRequestAttributesDuringDispatch.java:44)
         at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
         at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
         at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
         at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.java:267)
         at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:469)
         at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:140)
         at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:189)
         at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193)
         at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._renderResponse(LifecycleImpl.java:800)
         at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:294)
         at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:214)
         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.help.web.rich.OHWFilter.doFilter(Unknown Source)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:205)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:106)
         at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
         at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
         at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
         at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:271)
         at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:177)
         at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:175)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
       SUBSYSTEM : HTTP
       USERID : <WLS Kernel>
       SEVERITY : Error
       THREAD : [ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'
       MSGID : BEA-101017
       MACHINE : vm0-jpawlows.amg.net.pl
       TXID :
       CONTEXTID : 2910bfe82460a9b3:63a8fc67:1328fe13615:-8000-00000000000022a6
       TIMESTAMP : 1316676096720
    Diagnostic Dumps
    Name: jvm.threads
    Dump Files: jvm_threads13_i3.dmp
    Name: dms.metrics
    Dump Files: dms_metrics14_i3.dmp
    Name: odl.quicktrace
    Dump Files: odl_quicktrace15_i3.dmp
    Name: odl.logs
    Dump Arguments: ecid=2910bfe82460a9b3:63a8fc67:1328fe13615:-8000-00000000000022a6
    Dump Files: odl_logs16_i3.dmp
    Name: odl.logs
    Dump Arguments: timestamp=1316676096814
    Dump Files: odl_logs17_i3.dmp
    Name: wls.image
    Dump Files: diagnostic_image_soa_server1_2011_09_22_09_21_48.zipKuba

    Hi Kuba
    I guess you are getting this error in Linux Env and not Windows. Basically SOA/BPM opens lots of files (JARs and WARs) and I guess it do not close them properly. The root cause for your error is something else. Here is the fix. This should work.
    Login into the linux machine with the root user privileges. Or ask the person who have root privileges to do this. Basically you have to increase the open file limits to much bigger number like 8192.
    To change the open file limits, login as root and edit the /etc/security/limits.conf file. If the following lines are already there, just change the number to 8192. Otherwise add below 2 lines exactly. Means for all the users on this OS, the nofiles is set to 8192, instead of single user.
    * hard nofile 8192
    * soft nofile 8192
    after this, make sure to RESTART the Linux box. Otherwise changes will not get reflected.
    Login into unix box from any client and run this command and it should return 8192
    ulimit -n
    Then start the soa server and you should be all set. Let me know if this fixes your issue (I am hoping it should).
    Thanks
    Ravi Jegga

  • Problem with pre-compiling jsp's

              hi,
              we have an .ear running on wls 6.0 sp2.
              Our app has a web component(part of the .ear) as well which has tld's & jsp.We
              are following the struts framework.
              We configured the <jsp-descriptor> element in the weblogic.xml file to pre-compile
              the jsp's..but the server complains of the following
              any suggestions would be appreciated
              ==================================================================================================================================
              <Jan 9, 2002 4:00:06 PM EST> <Error> <HTTP> <[WebAppServletContext(3001228,ppp)]
              failure pre-compiling JSP's
              java.lang.NullPointerException
              at weblogic.servlet.jsp.Jsp2Java.makeReader(Jsp2Java.java:232)
              at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:112)
              at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:253)
              at weblogic.servlet.jsp.Precompiler.compileOne(Precompiler.java:124)
              at weblogic.servlet.jsp.Precompiler.compile(Precompiler.java:44)
              at weblogic.servlet.internal.WebAppServletContext.precompileJSPs(WebAppServletContext.java:2003)
              at weblogic.servlet.internal.dd.DescriptorLoader.initFromWebApp(DescriptorLoader.java:742)
              at weblogic.servlet.internal.dd.DescriptorLoader.createServletContext(DescriptorLoader.java:359)
              at weblogic.servlet.internal.HttpServer.loadWARContext(HttpServer.java:467)
              at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:404)
              at weblogic.j2ee.WebAppComponent.deploy(WebAppComponent.java:74)
              at weblogic.j2ee.Application.addComponent(Application.java:133)
              at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
              at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:327)
              at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:143)
              at weblogic.management.mbeans.custom.WebServer.addWebDeployment(WebServer.java:76)
              at java.lang.reflect.Method.invoke(Native Method)
              at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:562)
              at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:548)
              at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:285)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
              at $Proxy44.addWebDeployment(Unknown Source)
              at weblogic.management.configuration.WebServerMBean_CachingStub.addWebDeployment(WebServerMBean_CachingStub.java:1012)
              at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:313)
              at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:277)
              at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:232)
              at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:192)
              at java.lang.reflect.Method.invoke(Native Method)
              at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:562)
              at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:548)
              at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:285)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
              at $Proxy41.updateDeployments(Unknown Source)
              at weblogic.management.configuration.ServerMBean_CachingStub.updateDeployments(ServerMBean_CachingStub.java:2299)
              at weblogic.management.mbeans.custom.ApplicationManager.startConfigManager(ApplicationManager.java:240)
              at weblogic.management.mbeans.custom.ApplicationManager.start(ApplicationManager.java:122)
              at java.lang.reflect.Method.invoke(Native Method)
              at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:562)
              at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:548)
              at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:285)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:439)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
              at $Proxy33.start(Unknown Source)
              at weblogic.management.configuration.ApplicationManagerMBean_CachingStub.start(ApplicationManagerMBean_CachingStub.java:435)
              at weblogic.management.Admin.startApplicationManager(Admin.java:1033)
              at weblogic.management.Admin.finish(Admin.java:493)
              at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:429)
              at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:170)
              at weblogic.Server.main(Server.java:35)
              >
              <Jan 9, 2002 4:00:06 PM EST> <Debug> <HTTP> <Exception thrown while loading ppp:
              weblogic.utils.NestedException: failure pre-compiling JSP's - with nested exception:
              [java.lang.NullPointerException]>
              <Jan 9, 2002 4:00:06 PM EST> <Error> <J2EE> <Error deploying application ppp:
              Could not load ppp>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[HTTP myserver] Loading web app: wl_management_internal2>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[HTTP myserver] Loading wl_management_internal2
              from WAR file: C:\engr\project\ppp\.\config\Synchronoss\applications\.wl_temp_do_not_delete\wl_local_comp45831.war>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[Default WebApp] extracting classfiles
              to C:\engr\project\ppp\.\config\Synchronoss\applications\.wl_temp_do_not_delete\WEB-INF\_tmp_war_myserver_myserver_wl_management_internal2:>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[Default WebApp] extracted classfiles
              successfully...>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(6559849,wl_management_internal2)]
              registering JSPServlet with initArgs '[JspConfig: verbose=true,packagePrefix=jsp_servlet,-compiler=javac,compileFlags=,workingDir=C:\engr\project\ppp\.\config\Synchronoss\applications\.wl_temp_do_not_delete\WEB-INF\_tmp_war_myserver_myserver_wl_management_internal2,pageCheckSeconds=1,superclass=null,keepgenerated=false,encoding=null,defaultfilename=index.jsp,noTryBlocks=false]'>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(6559849,wl_management_internal2)]
              registering classpath servlet with initArgs 'null'>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(6559849,wl_management_internal2)]
              registering getior servlet with initArgs 'null'>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <J2EE> <Deployed : wl_management_internal2>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <J2EE> <Deployed MailSession named com.bea.wlpi.MailSession>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <Initializing WEB server myserver>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[HTTP myserver] Loading web app: DefaultWebApp_myserver>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[HTTP myserver] Loading DefaultWebApp_myserver
              from directory: .\config\Synchronoss\applications\DefaultWebApp_myserver>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(4157813,DefaultWebApp_myserver)]
              registering JSPServlet with initArgs '[JspConfig: verbose=true,packagePrefix=jsp_servlet,-compiler=javac,compileFlags=,workingDir=C:\engr\project\ppp\.\config\Synchronoss\applications\DefaultWebApp_myserver\WEB-INF\_tmp_war_myserver_myserver_DefaultWebApp_myserver,pageCheckSeconds=1,superclass=null,keepgenerated=false,encoding=null,defaultfilename=index.jsp,noTryBlocks=false]'>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(4157813,DefaultWebApp_myserver)]
              registering classpath servlet with initArgs 'null'>
              <Jan 9, 2002 4:00:06 PM EST> <Info> <HTTP> <[WebAppServletContext(4157813,DefaultWebApp_myserver)]
              registering getior servlet with initArgs 'null'>
              

    [att1.html]
              

  • Problem in jsp with container(JEUS)

    Hi I am a developer in Korea
    Nowadays I have a problem in jsp pages which have contained some pakage directive in a library path
    so my problem is changing some of the classes in the package during service time.
    Error result is
    -Root Exception stack trace :
    -jeus.servlet.jsp.compiler.JspCompileException: fail to compile : source = C:\TmaxSoft\JEUS6.0\webhome\epims_container1\_generated_\j2ee-modules\harweb\jeus_jspwork\_custermg\_html\_mypage\_600_MyReqJob_5fjsp.java, -error msg = C:\TmaxSoft\JEUS6.0\webhome\epims_container1\_generated_\j2ee-modules\harweb\jeus_jspwork\_custermg\_html\_mypage\_600_MyReqJob_5fjsp.java:76: cannot access custermg.MyPageQuery
    bad class file: C:\epims\harweb\WEB-INF\classes\custermg\MyPageQuery.class
    -class file has wrong version 8241.8224, should be 49.0
    -Please remove or make sure it appears in the correct subdirectory of the classpath.
    -     MyPageQuery myquery = null;
    I don't know why this could be happed in random period of time It happens nearly each 10 hours . after this failure, the same error happen in other classes.
    Before ten hours?.... No problem with the jsp pages
    The number 8241.8224 tells me that it is not generated by java compiler but I don't have any clue but the above error
    my run time environment is
    - HP Server, Windows Server 2003, 64bit
    - Jeus, jdk1.5.0_15
    so any help from you will be appreciated...
    thanks

    Mr. Ahmed,
    Excuse-me by my bad english.
    I experienced the same problem when surrounded my scripts with comment caracters:
    <!--
    < SCRIPT ...
    -->
    If this is your case, simply uncomment it and the script will work fine.

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

  • Can not compile php with "-with-oracle=/usr/local/oracle"

    I work on Linux engine with a x86_64 architecture and use Oracle 10g 10.2.0.1 client for x86_64 linux
    so - when i try to compile php with the oracle argument (-with-oracle=/usr/local/oracle) i get everytime the same error:
    checking Oracle version... configure: error: Oracle needed libraries not found
    I think, maybe i have a problem because configure not found my "64 bit libraries"...
    Can someone help me? I am realy helpless...
    thx

    Did you really want the obsolete "oracle" driver - why not use --with-oci8?
    The user comments in http://www.php.net/oci8 have some good info on 64bit configuration.

  • BUG in Oracle SQL Developer 3.0.04 on the "generating DLL" with comments?

    I'm newbie on oracle, but I think that I found out a bug in Oracle SQL Developer version 3.0.04 on the "generating DLL" tool using "comments".
    I will describe the steps that I gave:
    I created a view, but after I test it I had to change my “where” condition, so I comment the old code and then I wrote the new “where” condition below. After I done that I tried to look at the sql code of my view using “generating DLL” tool, but oracle sql developer only shown me half of the code, a lot of code were missing. Then I began with some test trying to understand what happen and I notice that if I put an invalid sql code in my comment the generating DLL start working with no problems, for example(pseudo-code):
    (COMMENT WITH VALID SQL CODE the "Generating SQL" don't work:)
    CREATE OR REPLACE VIEW <user>.<view_name> ( <column1>,<column2> )
    AS
    SELECT column1, column2
    FROM table1
    INNER JOIN
    (SELECT
    FROM table2
    INNER JOIN .....
    INNER JOIN ....
    --where time_stamp = (select max(time_stamp) from .....)
    WHERE time_stamp >= TRUNC(sysdate)
    ) t1 ON t1.ID = ....
    AND ..... >= TRUNC(sysdate)
    ORDER BY ....
    Generating DLL returns this(when the error occurs):
    CREATE OR REPLACE VIEW <user>.<view_name> ( <column1>,<column2> )
    AS
    (COMMENT WITH VALID SQL CODE the "Generating SQL" work with no problems:)
    CREATE OR REPLACE VIEW <user>.<view_name> ( <column1>,<column2> )
    AS
    SELECT column1, column2
    FROM table1
    INNER JOIN
    (SELECT
    FROM table2
    INNER JOIN .....
    INNER JOIN ....
    --where
    WHERE time_stamp >= TRUNC(sysdate)
    ) t1 ON t1.ID = ....
    AND ..... >= TRUNC(sysdate)
    ORDER BY ....
    I believe that "Generating DLL" tool have some problem with the comments, I also used /*...*/ to comment but the problem is still active.
    I notice as well that if I started to add some more comments along the code, the conditions migth change, so I think the problem is related with "comments" code.
    Would you mind telling me if this is a real bug or if I'm doing anything wrong.
    Thank you in advance,
    Rodrigo Campos
    Edited by: 894886 on 3/Nov/2011 5:29

    Hi Rodrigo,
    Thank you for reporting this. The only bug I see currently logged on a comment affecting the generated View DDL involves ending the last line of the definition with a comment, which treats the ending semi-colon (even if on a different line) as part of the comment. That is actually related to a low-priority bug against an Oracle database API.
    Unfortunately, your pseudo-code is a bit complex. Trying a few quick, simpler tests against the standard HR schema did not reproduce the issue. I tried INNER JOIN, and nested SELECTs. It would help greatly if you could provide a test case compilable against one of the standard schema, like HR or SCOTT.
    Regards,
    Gary
    SQL Developer Team

  • Problem in JSP with JavaScripts, which works perfectly in TOMCAT

    The peice of code below works without any problem in tomcat, which assign some values from a form named "frmOffice" which is in another jsp. In 9iAS it seems the values are not found. Also it says 'error on page'. What could be the reason. Please respond as soon as possible. Thanks.
    <SCRIPT Language="JavaScript">
    function Opennewwindow(url,size)
    window.open (url,"Newwindow",size);
    function NewContact()
    var UserID =
    parent.parent.frmMenubar.document.frmOffice.UserID.value;
    var GroupID =
    parent.frmFolderHead.document.fomFolderHead.FolderID.value;
    var intDomainID =
    parent.parent.frmMenubar.document.frmOffice.DomainID.value;
    Opennewwindow('../../modules/contact/Contact_New.jsp?
    UserID='+UserID+'&GroupID='+GroupID+'&Email=&DomainID='+intDomainID,'scrollbars=1,width=680,height=190');
    </SCRIPT>

    Mr. Ahmed,
    Excuse-me by my bad english.
    I experienced the same problem when surrounded my scripts with comment caracters:
    <!--
    < SCRIPT ...
    -->
    If this is your case, simply uncomment it and the script will work fine.

Maybe you are looking for

  • PDF document in Java application

    Hi All, Is it possible to show a PDF document in Java application, Using JEditorPane or.....? Regards, Byju

  • Remove domain account on remote computer using its local credentials

    I want to make a script that will remove domain user account from remote computer. Right now I tested dosen of methods. I have stick to this: ([ADSI]"WinNT://$computerName/$localGroupName,group").Remove("WinNT://$domainName/$userName") Thats absolute

  • DNG converter question

    I apologize for asking this question in this forum. But the DNG forum is not very active it seems. I have seen this problem mentioned in the past, but paid no attention to it and I can't find any of the references. I have no convert button on my DNG

  • Worklist API

    Hi, Please let me know if bpm 11g worklist API jars comes default with oracle bpm and the location of the jar files. Regards, Sam

  • Convert to Profile (Applescript)

    Hi All, I'm looking for an applescript command to perform "Convert to Profile" on my current document in Photoshop CS3. I've seen a Javascript solution in this Forum, but nothing for applescript. Any help would be appreciated. I would also love to kn