Saturday, December 15, 2012

Never forget resetActionListener when there is rollbackTransaction action


Whenever you put a button (any action component) to rollbackTransaction make sure you have resetActionListener also.. Usually when you drag and drop rollback operation as action component this is created by default. But in the scenarios where you add action component separately you have to put it manually..

Many times I missed to put resetActionListener inside my button and the application data looks very odd when I click Cancel button... And I spent hours to debug the issue and found that resetActionListener  is missing..

<af:commandToolbarButton text="#{viewcontrollerBundle.DISCARD_CHANGES}" id="ctb2"
                                                   icon="/images/Discard.png" accessKey="Z"
                                                   actionListener="#{ManagedBean.rollbackChanges}" immediate="true">
         <af:resetActionListener/>
</af:commandToolbarButton>

So never forget(saying to myself) resetActionListener and rollbackTransaction!!

Jdeveloper 11.1.2.0 & Debug Mode

When you run the application in Debug mode in Jdeveloper 11.1.2.0, compile any java file and refresh the page you get java.lang.NullPointerException.

This issue is discussed in detail at
https://forums.oracle.com/forums/thread.jspa?threadID=2244097&tstart=0

and the summary is:
------------------------------------------------------------------------------------------
Option 1:  Change Tools->Preferences->Run->WebLogic and setting Select Hot Class Reload Policy to Fast Swap.

Option 2 : Turn off copying of any rebuilt files into the exploded EAR.
Usually the jdev shortcut target will be:
C:\Oracle\Middleware\jdeveloper\jdeveloper.exe

Modify this to C:\Oracle\Middleware\jdeveloper\jdeveloper.exe -J-Doracle.jdeveloper.adrs.incr.buildMonitor=false
and then restart jdeveloper.

Please use option 2 as a last resort. Since the debugger already provides some support for class redefinition, perhaps this will be useful for many who use debug mode.
------------------------------------------------------------------------------------------

I set Option 1 and it was working fine. But my weblogic server started crashing intermittently. I'm still working on exact reproducible steps but meanwhile I tried option 2 and it works properly.

East to West

Moved to California from New York.. Just got settle down..

Next posts are on the way...

Thiru

Monday, October 22, 2012

Wednesday, October 3, 2012

Jdeveloper Remote Debugging

Sometimes we see application issues on standalone weblogic server which is not reproducible while running the same application in integerated weblogic server inside Jdeveloper..

The best option is remote debugging.. Its very simple to setup..

1. Open the file $DOMAIN_HOME/bin/setDomainEnv.cmd
    a. set debugFlag = true
    b. Disable assertions: search for -ea and replace it with -da (keep a backup to restore it)
    c. Note down the debug_port (default is 8453).
    d. Start weblogic server. Make sure that you see Listening for transport dt_socket at address: 8453 in the
        Server log file.


2. On Jdeveloper:

Right click your project -> Project Properties


Run/Debug/Profile -> Edit


 Select Remote debugging



On Same Window, Select Tool Settings -> Debugger -> Remote and have the following settings.

Protocol -> Attach to JPDA
Host: Host of your WLS Server
Port: WLS Debugger port, default is 8453.


Right click your project, Start Remote Debugger.






That's it.. Now you have connected your remote application in debug mode.. Put breakpoints on your code and see what's going on..

Happy Debugging :-)

Note : Please make sure that the code you have deployed in weblogic server and the code you have connected from jdeveloper are same.

Monday, August 6, 2012

NYC Oracle JDeveloper Meetup

Are you in New York and working in JDeveloper??

Feel free to join NYC Oracle JDeveloper Meetup and lets share our experiences, issues, designs, etc..



Thiru

Thursday, July 26, 2012

Multiple Root Application Module to One Root Application Module

Was quite busy in AM pooling and database connections issue.. but interesting issue..

3 years back somebody designed my application with 7 root AM's and its working fine with few users... but in next few months we are going to have 300+ concurrent users..

We don't want to..
 - take 2100 database connections..
 - have frequent activation and passivation..
 - change the application design to have one main taskflow and let all other task flow to share the transaction...

And we just got 4 weeks to fix this... What is the option I left with.. Create a new root application module and make existing 7 AM's nested.. but we got more than 200 pageDef.. I need atleast 4 months to change everything declaratively and test it thoroughly.. not enough time to do this..


So what I have done is.. Created a new sample application with one root AM and one nested AM.. created a task flow and a page with all kinds of bindings declaratively... closely observed the patterns in pageDef files.. Just following the pattern and wrote a small piece of java code which will replace all the pageDef root AM references to use nested AM references.. And yes it worked out.. Just one day coding and 3 weeks testing.. Now on average 1 User 1 DB Connection... I think the best way would be xslt but I'm not familiar with that and I don't have much time to experiment that.. So went with my favorite java code..


I'm sure the same situation will be faced by other developers also.. So I'm sharing my code here.. Just follow the below steps:


1. Create a new Application Module (Say TestRootAM) and make all your existing AM's as nested of RootAM.


2. Create a datacontrol usage in DataBindings.cpx for the new AM. (Simple way is to drag and drop an attribute from a nested AM which will create this entry automatically) Also remove all other datacontrol usages from DataBindings.cpx


3. Download my java code and set proper value for variables
ROOT_AM_NAME (new AM name TestRootAM ) and 
ROOT_DIR (root directory of pageDef files) 
and then run it.. It will replace all root AM references to use nested AM references.

4. Test your application and make sure everything works fine.

Do not forget to change the new AM configurations..

That's it now my application code/design looks same as if it would have been implemented declaratively via jdeveloper with one root AM and multiple nested AM.

In future if you don't want to make any other AM's as root AM then hide all nested AM data controls as per my earlier post.

Also this script will fix Oracle ADF Bug 13837650 which I mentioned in my earlier post.

Good luck and incase if you find any issues in my script please put your comments so that I will modify it. 

Note : Please note that I'm just sharing the code for reference and its your responsibility to use this and test your application thoroughly.

Thiru

Monday, July 2, 2012

Hide data controls from data control panel

We designed our application to have one Root AM, one shared AM and multiple nested AM's to have minimum number of database connections. 

Need to hide the Nested AM data controls so that we do not drag and drop method call or view object mistakenly from Nested AM Data Control. 

To hide the data control in data control panel, set the AM Library Private property True


Saturday, June 30, 2012

Bind values set for a VO on nested AM method call activity is not reflected in my page

And finally my first informative post is here:

When you have a taskflow which does not share datacontrol 



and it has a methodCall and view activities.



Here if this method call activity is created from a nested AM then the pageDef binding will be:



With this code the bind parameters set on the method call activity will not be reflected in the view activity. 

The reason is ADF creates 2 application modules here, one for method call activity and another for view activity. So the view object in view activity does not have the bind parameters applied in method call activity.

This issue is due to 'Root' keyword in instanceName attribute.

Change the instance name attribute from:   
    InstanceName="AppRootAMDataControl.dataProvider.Root.DeptEmpAM1">
to 
    InstanceName="AppRootAMDataControl.dataProvider.DeptEmpAM1"

to fix this issue.

Initially I was wondering why the bind parameters are lost and after some detailed analysis I found that both are different AM instances and logged SR with reproducible test case. Then Oracle Support asked me to remove the Root keyword and also they confirmed that the issue will be fixed via 
Bug 13837650: REMOVE ROOT FROM THE INSTANCE NAME OF METHODACTION BINDING

Looks like this bug is planned for JDeveloper 12.1 release, till that time if you create action or MethodAction make sure that Root is removed manually.

For my detailed analysis and reproducible test case refer my Oracle Forum Post.

Wednesday, April 18, 2012

My First Post

It's a long time plan to create my blog, keep my learning's at single place and share it with others. And finally its live now.

I'm Thirumalaisamy Thangavel and I work as Senior ADF Consultant. I have around 6 years of experience in Oracle Technologies such as ADF, BI Publisher, Java, EBS and Fusion Financials.

Everyday I see different features of ADF, component properties, various implementations and also I write some generic util scripts. Its tough to remember everything. So I'm starting this blog to keep all my learning's at single place as a reference and also would like to share with others.