sexta-feira, 5 de dezembro de 2014

java.lang.OutOfMemoryError while compiling weblogic.appc is running

Hello all,

This week, after 2 months waiting Oracle to answer me in MOS I finally got the solution for my problem.

The weblogic.appc tool pre-compiles each JSP file before deploying your project to Integrated WLS, otherwise your application could take a big performance hit as it needs to compile each .JSP file after the first request. This so called "feature" could get you in some trouble if you have more 400+ .jsp files, the fact lies beyond the heap parameters in weblogic.appc compiler, the default values (-Xms128 and -Xmx512) aren't enough to a big project like that.

After some analysis Oracle Support offered me two solutions:

  • 1) Start JDeveloper with the following argument from command-line: 



      jdevW.exe -J-Djdev.webapp.appc.addition.jvmargs=-Xmx1025m 

    Important: this argument is for internal development, hence is not officially supported and is subject to change or removal. 

    See if you can compile the project. 

    You'll notice an output like this in the compiler log: 
    C:\Oracle\jdev111170\jdk160_24\jre\bin\javaw.exe -Xms128m -Xmx512m -XX:MaxPermSize=128m -Xverify:none -client -classpath C:\Oracle\jdev111170\jdk160_24\lib\tools.jar;C:\Oracle\jdev111170\wlserver_10.3\server\lib\weblogic.jar -Dweblogic.jsp.diagnosticWithAbsolutePath=true -Dweblogic.classloader.noJarSigners=true -Xmx1025m weblogic.appc "@C:\Users\wperezs\AppData\Local\Temp\appcCommandList4301097272113615486.txt" 

    Notice that argument -Xmx shows twice: the first is internally passed by JDev and the second is the one we are passing with above argument. 
    This is because is not possible to override arguments we are passing internally through JDeveloper. 

    2) If the above didn't help, are left with the following options: 

    a) Disable compilation at DT when deploying to to Integrated Weblogic Server. 

    Uncheck "Compile JSP before deploying to Integrated Weblogic Server" checkbox in Project Properties > Compiler > JSP. 
Both of them worked and now my project is compiling fine. I'm thinking about permanently disabling the JSP pre-compilation as we do far more deploys locally than remote.

quarta-feira, 26 de fevereiro de 2014

ViewObject Forward Only mode


Today I was reading a interesting topic about one of ViewObject tuning properties, it is called Forward Only mode, you can programmatically set it by calling setForwardOnly(true). This property won't allow the ViewObject to cache the previous loaded rows while RowSet scroll is happening.

Link to the documentation:


39.2.6 Use Forward Only Mode to Avoid Caching View Rows

As stated in documentation:
"Often you will write code that programmatically iterates through the results of a view object. A typical situation will be custom validation code that must process multiple rows of query results to determine whether an attribute or an entity is valid or not. In these cases, if you intend to read each row in the row set a single time and never require scrolling backward or re-iterating the row set a subsequent time, then you can use "forward only" mode to avoid caching the retrieved rows. To enable forward only mode, call setForwardOnly(true) on the view object.

Using a read-only view object (with no entity usages) in forward-only mode with an appropriately tuned fetch size is the most efficient way to programmatically read data.
You can also use forward-only mode to avoid caching rows when inserting, updating, or deleting data as long as you never scroll backward through the row set and never call reset() to set the iterator back to the first row. Forward only mode only works with a range size of one (1)."

Good to know!

sábado, 15 de fevereiro de 2014

Accessing ViewObjectImpl sample methods trough Groovy


Here are two ViewObjectImpl sample methods, one using direct Where Clause modification and another one using ViewCriteriaRow API:


    private static ADFLogger LOGGER =
    private String minimumSalaryWhereClause = "MIN_SALARY IN (SELECT MIN(MIN_SALARY)\n" +
                                              "                 FROM HR.JOBS)\n" +
                                              "       AND ROWNUM = 1";
    private String minimumSalaryWhereClauseVC = "SELECT MIN(MIN_SALARY)\n" +
                                                "  FROM HR.JOBS\n";

    public String getJobWithMinimumSalary() {
        LOGGER.warning("WHERE clause -> " + this.getWhereClause());

        String jobId = "SH_CLERK";
        if (first() != null) {
           jobId = (String)first().getAttribute("JobId");
        LOGGER.warning("Selected JobId -> " + jobId);
        LOGGER.warning("WHERE being reseted -> " + this.getWhereClause());

        return jobId;


    public String getJobWithMinimumSalaryVCVersion() {
        ViewCriteria minimumSalaryVc = createViewCriteria();
        ViewCriteriaRow vcRow = minimumSalaryVc.createViewCriteriaRow();
        ViewCriteriaItem criteriaItem = vcRow.ensureCriteriaItem("MinSalary");

        return (String)first().getAttribute("JobId");

Two methods that does exactly the same thing but with slightly different approach. After that suppose that you want to populate the JobId attribute in Employees View Object with the previous created method return:

Don't forget to mark the Default Value indicator as "Expression", that will take care of Groovy interpretation process. Run trough AppModule tester to see runtime generated queries of both methods.