20110419 forcing recompile of osso loginjsp - plembo/onemoretech GitHub Wiki

title: Forcing recompile of OSSO login.jsp link: https://onemoretech.wordpress.com/2011/04/19/forcing-recompile-of-osso-loginjsp/ author: lembobro description: post_id: 48 created: 2011/04/19 17:44:06 created_gmt: 2011/04/19 17:44:06 comment_status: open post_name: forcing-recompile-of-osso-loginjsp status: publish post_type: post

Forcing recompile of OSSO login.jsp

This is one that my colleague, Shashi S., came up with after everyone, including Oracle Support, failed. The problem initially presented as a “user unable to log in to EBS”. But the screenshot told us that the issue was with our Oracle AS 10g R3 SSO server. Here’s the ugly error text we saw:

500 Internal Server Error
OracleJSP: oracle.jsp.provider.JspCompileException: 
Errors compiling:
/u01/app/oracle/product/sso/j2ee/OC4J_SECURITY/application-deployments 
/sso/web/persistence/_pages/_pages/_login.java
error: error reading ../../jlib/../j2ee/home/../../jlib/../j2ee/home/.. 
/../jlib/../j2ee/home/../../jlib/../j2ee/home/../../jlib/
	
***
../j2ee/home/lib/servlet.jar; zip file name too long
 
 
The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.(ZipFile.java:203)
        at java.util.zip.ZipFile.(ZipFile.java:84)
        at com.sun.tools.javac.jvm.ClassReader.openArchive(ClassReader.java:1439)
        at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1742)
        at com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882)
        at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1903)
        at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
        at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:256)
        at com.sun.tools.javac.tree.Tree$TopLevel.accept(Tree.java:382)
        at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:221)
        at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:235)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:444)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:429)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:404)

That’s a pretty scary message to see coughed up into your browser window. Our initial thought, confirmed by Oracle, was that redeploying the sso.war file would do the trick. It didn’t. Then Shashi took a look at it and determined (from the part of the stack trace that complains about login.java above) that the right procedure was to force recompilation of the login.jsp and logout.jsp files under $OH/j2ee/OC4J_SECURITY/applications/sso/web/pages. To do this, he: 1. Ran touch against login.jsp and logout.jsp; 2. Went down into $OC4J_SECURITY/application-deployments/sso/web/persistence/_pages/_pages and deleted the _login.java and _logout.java files he found there; and 3. Restarted OC4J_SECURITY (opmnctl stopproc ias-component=OC4J_SECURITY; opmnctl startproc OC4J_SECURITY). That did it. When OC4J came back up it detected that the two .jsp files had been changed and recompiled them.

Copyright 2004-2019 Phil Lembo