Comments Off

By Jay, March 23, 2012

Chris Muir provides an excellent article, explaining in detail what causes the above error and how to resolve it. Thanks Chris. Others: Enjoy reading

Comments (1)

By Jay, March 19, 2012

Even though I would love to buy two light boxes, for now I should consider making inexpensive light boxes as explained in this page. Hope this efforts and the results I produce allow me to spend more time with my camera during weekends than spending in front of my computer.

Comments Off

By Jay, March 5, 2012

It is quite easy to change the port, TNS Listener process is currently listening to. I tried this on Oracle Express Edition (XE) database running on my laptop. Here is what I did …
D:>sqlplus
Enter user-name: system
Enter password:
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
SQL> begin
2 dbms_xdb.sethttpport('8181');
3 end;
4 /
PL/SQL procedure successfully completed.
SQL> exit
Disconnected from Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production


Comments Off

By Jay, March 4, 2012

Five imperatives that companies / organizations need to act on if they want to win the war for managerial talent and make talent a competitive advantage:

1. Embrace a talent mindset
2. Craft a winning employee value proposition
3. Rebuilding your recruiting strategy
4. Weave development into your organization
5. Differentiate and affirm your people

Comments Off

By Jay, March 3, 2012

Most of you may already know about TCPView, if you are hooked to Microsoft OS. It shows detailed listings of all TCP and UDP endpoints on your system, including the local and remote addresses and state of TCP connections. You can find more information about TCPView here.

Comments Off

By Jay, March 2, 2012

The Old Reality

1. People need companies
2. Machines, capital and geography are the competitive advantage
3. Better talent makes some difference
4. Jobs are scarce
5. Employees are local and jobs are secure
6. People accept the standard package they are offered

The New Reality

1. Companies need people
2. Talented people are the competitive advantage
3. Better talent makes a huge difference
4. Talented people are scarce
5. People are mobile and their commitment is short term
6. People demand much more

Comments Off

By Jay, March 1, 2012

David Giammona has posted an excellent article on best practices for sharing data and initiating navigation within ADF regions. It describes each of the different ADF Region interaction development approaches and their recommended uses. Examples are also provided to help demonstrate each of the concepts.

Comments Off

By Jay, February 1, 2012

First, you need to set the session variable. This is done generally as part of the authentication process. ADF provides UserData – an Hashtable in which you can store your session variable.

this.getSession().getUserData.put(key,value);

For example, you can write

this.getSession().getUserData.put("AppsUserId", appsUserId);

Now, if you want to set the default value of an attribute belonging to an Entity Object, you can specify the following Groovy expression:
adf.securityContext.userData.UserId

To update the history WHO columns such as CREATED_BY, UPDATED_BY etc, you can override the method getHistoryContextForAttribute() in your extended custom EntityImpl class:

protected Object getHistoryContextForAttribute(AttributeDefImpl attr) {
  byte historyKind = attr.getHistoryKind();
  if ((historyKind == AttributeDefImpl.HISTORY_CREATE_USER) ||
      (historyKind == AttributeDefImpl.HISTORY_MODIFY_USER)) {
    return this.getDBTransaction().getSession().getUserData().get("AppsUserId");
  }
  ...
  ...
}

And finally, set the Track Change History for the attribute in the Entity Object editor. For example, the following shows how it is set for the attribute CreatedBy:

That’s it

Comments Off

By Jay, January 21, 2012

Managed beans are Java classes that are registered with the application using various configuration files. When the JSF application starts up, it parses these configuration files, and the beans listed within them are made available. The managed beans can be referenced in an EL expression, allowing access to the beans’ properties and methods. Whenever a managed bean is referenced for the first time and it does not already exist, the Managed Bean Creation Facility instantiates the bean by calling the default constructor method on it. If any properties are also declared, they are populated with the declared default values.
As best practice, use managed beans to store logic that is related to the UI rendering only, while all application data and processing are handled by logic in the business layer of the application. Storing business related logic in the middle-tier allows this logic to expose as business service methods, which can then become accessible to the ADF Model layer and be available for data binding.
In an application that uses ADF data binding and ADF task flows, managed beans are registered in different configuration files from those used for a standard JSF application. In a standard JSF application, managed beans are registered in the faces-config.xml configuration file. In a Fusion web application, managed beans can be registered in the faces-config.xml file, the adfc-config.xml file, or a task flow definition file. Which configuration file you use to register a managed bean depends on what will need to access that bean, whether or not it needs to be customized at runtime, what the bean’s scope is, and in what order all the beans in the application need to be instantiated.
Registering managed beans within the faces-config.xml file is not recommended in a Fusion web application. Managed beans accessed within the task flow definition must be registered in that task flow’s definition file.

Effects of Managed Bean Configuration Placement

• adfc-config.xml
1. Managed bean can be of any scope. However, any backing beans for page fragments or declarative components should use BackingBean scope.
2. When executing within an unbounded task flow, faces-config.xml will be checked for managed bean definitions before the adfc-config.xml file.
3. Lookup precedence is enforced per scope. Request-scoped managed beans take precedence over session-scoped managed beans. Therefore, a request-scoped managed bean named foo in the adfc-config.xml file will take precedence over a session-scoped managed bean named foo in the current task flow definition file.
4. Already instantiated beans take precedence over new instances being instantiated. Therefore, an existing session-scoped managed bean named foo will always take precedence over a request-scoped bean named foo defined in the current task flow definition file.
• Task flow definition file
1. Managed bean can be of any scope. However, managed beans of request scope, of pageFlow scope, of view scope, or with the scope set to none that are to be accessed within the task flow definition must be defined within the task flow definition file. Any backing beans for page fragments in a task flow should use BackingBean scope.
2. Managed bean definitions within task flow definition files will be visible only to activities executing within the same task flow.
3. When executing within a bounded task flow, faces-config.xml will be checked for managed bean definitions before the currently executing task flow definition. If no match is found in either location, adfc-config.xml and other bootstrap configuration files will be consulted. However, this lookup in other adfc-config.xml and bootstrap configuration files will only occur for session- or application-scoped managed beans.
4. Lookup precedence is enforced per scope. Request-scoped managed beans take precedence over session-scoped managed beans. Therefore, a request-scoped managed bean named foo in the adfc-config.xml file will take precedence over a session-scoped managed bean named foo in the current task flow definition file.
5. Already instantiated beans take precedence over new instances being instantiated. Therefore, an existing session-scoped managed bean named foo will always take precedence over a request-scoped bean named foo registered in the current task flow definition file.
6. Customizations are allowed.
• faces-config.xml
1. Managed beans can be of any scope other than pageFlow scope or view scope.
2. When searching for any managed bean, the faces-config.xml file is always consulted first. Other configuration files will be searched only if a match is not found. Therefore, beans registered in the faces-config.xml file will always win any naming conflict resolution.
3. No customizations can be made.

As a general rule for Fusion web applications, a bean that may be used in more than one page or task flow, or one that is used by pages within the main unbounded task flow (adfc-config), should be registered in the adfc-config.xml configuration file. A managed bean that will be used only by a specific task flow should be registered in that task flow’s definition file. There should be no beans registered in the faces-config.xml file.