June notes 2

1) Access session scope from BC layer is designed approach

This http://andrejusb.blogspot.sg/2012/01/how-to-access-session-scope-in-adf-bc.html blog entry was causing some objection by his audience because of tighter coupling of the layers but today I happened to see that it’s designed so by Oracle:


Access session value in groovy:

//is equivalent to:

2) Minify/Compress Javascript/CSS files

YUI Compressor: http://developer.yahoo.com/yui/compressor/#using

3) executeQueryForCollection seems not AM passivation friendly

for some non-database VO (eg. VO with all transient attributes), if we need to always have a blank row, override this method and insert an blank row if current row is null, this approach is working but seems not passivation/activation friendly. Better use the old approach: createinsert one row before hand or use static list VO with one data row.

4) CSS3 Animation: execute 2nd animation after first animation end


-webkit-animation: first 1s 6 ease-in alternate,
second 6s 6s infinite ease-in alternate;
-moz-animation: first 1s 6 ease-in alternate,
second 6s 6s infinite ease-in alternate;
-ms-animation: first 1s 6 ease-in alternate,
second 6s 6s infinite ease-in alternate;
animation: first 1s 6 ease-in alternate,
second 6s 6s infinite ease-in alternate;

Alternatively, could use javascript to bind animation end event (‘animationend’ is for Firefox):

$("#ball").bind("webkitAnimationEnd oAnimationEnd msAnimationEnd animationend", function(){


5) Nginx refresh configuration:

/etc/init.d/nginx reload

Nginx change location path and enable directory listing:
vi /etc/nginx/sites-enabled/default

server {
location / {
   root  /yourNewPath;
   autoindex on;

6) Some free pomodoro countdown timers (Time Management)
http://www.pomodoroapp.com/   (seems floating widget not shown on ubuntu 12.04LTS)

7) jQeury easing plugin:




Know this long time ago, put a bookmark here.

8) View Object Activation Error: JBO-27122 Missing IN or OUT parameter

One possible reason could be: a view criteria is applied on the VO but the “executeQuery()” is not invoked immediately after that. In this case, the parameter values in the view criteria will not be passivated and JBO-27122 may occur during VO activation.


9) View Object Passivation/Activation Related Error: java.sql.SQLException: Attempt to set a parameter name that does not occur in the SQL

If same view object instance is used in multiple service method in same AM with different view criteria is applied, above error may occur if the service methods are invoked with very short interval (related to thread safty? maybe, I am not sure). Anyway, it would be better to use different view object instance for different AM service methods.

10) activateCurrentRow may cause slowness & excessive memory usage during view object activation


Use case:

CreateInsert a new row into an iterator -> Display the row (not displaying multiple rows from the VO, eg: <af:table>) -> User modify data -> Save -> User modify data again -> Save -> Slowness

(Please note that above use case is different from the one in the Oracle forum post, which scroll to the bottom of the table and select last row as current row)

The method then may cause looping over entire table to find the row, possibly due to there’s no vc applied on the vo.


1) Create a service method in the application module to commit and immediately append a view criteria which has only the primary key as the where condition (or any view criteria that could result in not too many rows) to the view object if there’s currently no criteria applied on the vo   (verified approach). Invoke this service method for commit instead of using default Commit operation provided by AM. This is verified approach and probably using range paging will help too but I didn’t try. Because normally range paging is for resolving <af:table> slowness/memory issues while in this case, slowness/memory issue is produced without <af:table>.

2) Override the activateCurrentRow method (didn’t hv time to verified for all use cases)

protected ViewRowImpl activateCurrentRow(ViewRowSetIteratorImpl viewRowSetIteratorImpl,
    ViewRowSetImpl viewRowSetImpl, Key key) {
  ViewRowImpl ret = null;
    if(key!=null && !key.isNull() && viewRowSetImpl!=null){
      Row[]rows = viewRowSetImpl.findByKey(key, 1);
      ret = (rows!=null && rows.length>0)?(ViewRowImpl)rows[0]:null;
  }catch(Throwable e){
    logger.warning("error in findByKey",e);
    ret = super.activateCurrentRow(viewRowSetIteratorImpl, viewRowSetImpl, key);
    return ret;

Even 2nd approach is not used, it’s better to override this method and just track the time taken, print a warning message if the time is long.

Env: jdev11.1.2.4