View accessors in ADF Business Components are value accessor objects that point from an entity object attribute (or view object) to a destination view object or shared view instance in the same application workspace . The view accessor returns a row set that by default contains all rows from the destination view object. You can optionally filter this row set by applying view criteria to the view accessor. The base entity object or view object on which you create the view accessor and the destination view object need not be in the same project or application module, but they must be in the same application workspace.
Because view accessors give you the flexibility to reach across application modules to access the queried data, they are ideally suited for accessing view instances of shared application modules.
When you create a ViewAccessor at the entity level, accessing the same at the ViewObject level is a little tricky, especially if you want to have it as part of a groovy expression in a transient attribute. An expression that works is :
row = (object.getEntity(0).ViewAccessorName.first())
return (row == null) ? null : row.Name
Tuesday, November 29, 2011
Jdeveloper IDE table-inspector error
When you're working with jdeveloper and the ide gives the below error in the property inspector :
Error : Error constructing column editor
Reason : This mostly happens when the related AM data control is not loaded properly in the data controls section.
Soln : Clean, build, and deploy the model project.
Re-load the data controls region.
Now., clicking on the property inspector shud render the column editor for your table!!
Error : Error constructing column editor
Reason : This mostly happens when the related AM data control is not loaded properly in the data controls section.
Soln : Clean, build, and deploy the model project.
Re-load the data controls region.
Now., clicking on the property inspector shud render the column editor for your table!!
Friday, September 23, 2011
ORA-01031:insufficient privileges
I was stuck with this particular error as part of running my UI. Now, you know for sure that there is some username / password that you are using which does not have the required grants or privileges. Or it is some security related issue.
The log inside jdeveloper could actually sometimes be misleading, in that it could show a SQLstatement exception for some unrelated tables (EOs, VOs, etc).
However, running the SQL query that was shown as part of the log inside the SQL worksheet in jdev actually gave me the clue. I was able to reproduce the same ORA error with the username and password as fs_runtime. However, the error was gone once I changed to username to fs.
I had to subsequently change the credentials inside the properties file and re-created the domain, to help get rid of the error in UI!
Alternatively, giving grants to the username that does not have the required grants also works fine!
The log inside jdeveloper could actually sometimes be misleading, in that it could show a SQLstatement exception for some unrelated tables (EOs, VOs, etc).
However, running the SQL query that was shown as part of the log inside the SQL worksheet in jdev actually gave me the clue. I was able to reproduce the same ORA error with the username and password as fs_runtime. However, the error was gone once I changed to username to fs.
I had to subsequently change the credentials inside the properties file and re-created the domain, to help get rid of the error in UI!
Alternatively, giving grants to the username that does not have the required grants also works fine!
Sunday, July 17, 2011
ADF Lifecycle
The ADF Lifecycle provides support allowing a web page to interact with ADF Model data bindings. The lifecycle calls the correct binding container needed for a JSP or UIX page, updates values in the binding container's bindings if necessary, and
prepares the data to be rendered. The binding container stores this data locally before rendering the page.
Implementations of Lifecycle should be thread-safe and use the LifecycleContext object as the place to store any per-request state they may need.
ADF Lifecycle phases:
1. initialize
This phase initializes the values of the associated request, binding container and lifecycle. The method that is used from the Interface Lifecyle for this purpose is :
initializeMethodParameters(LifecycleContext lcContext, oracle.jbo.uicli.binding.JUCtrlActionBinding actionBinding)
This method is invoked before any ControlBinding or custom method is being executed.
2. prepareModel
This phase prepares and initializes the Model. Page parameters are set and methods in the executable section of the page definition of the ADF page are executed. The interface LifeCycle method used :
prepareModel(LifecycleContext lcContext)
3. applyInput
This phase handles the request parameters. These may come by adding the request parameters in the URL or as a result of HTML form post action. A list of events is build using these request parameters. These are actually mapped to the bindings in the pageDef. This phase resolves the list of request parameters bind to attributes in the page def. This results into a list of updatedValues which is used in Update Model phase.
The interface LifeCycle method used :
buildEventList(LifecycleContext lcContext)
Builds the list of events with their possible associated action binding from the request parameters.
4. validateInput
This phase validates the list of values built in the Apply input values field with model.
5. updateModel
This phase updates data model with the list of values created in apply input values phase.
The interface LifeCycle method used :
processUpdateModel(LifecycleContext lcContext)
Update the data model with values submitted in the request.
6. validateModelUpdates
This phase validates the Updates in the previous phase by calling the associated lifecycle's binding container .
The interface LifeCycle method used :
validateModelUpdates(LifecycleContext lcContext)
Forces model-level validation to occur.
7. Process Component Updates
This phase handles any events in the list built during the apply input values phase. Named events as well as all the events tied to the databindings created in the pagdef are handled in this phase.
The interface LifeCycle method used :
processComponentEvents(LifecycleContext lcContext)
Handle any events in the action binding list previously built in processUpdateModel using the buildEventList method.
8. Metadata Commit
This phase commits the runtime metadata changes to the model. This phase is always executed before prepare render phase.
9. Prepare Render
This is the final phase where page is sent for rendering. prepareRender event is sent to all the registered listeners. This notification signals bindings to prepare or process the data for rendering. Binding container is also refreshed. This helps
in updating any changes that happened during validation phases.
References :
- Lifecycle (Oracle Fusion Middleware Java API reference for Oracle ADF Lifecycle)
- Phases in ADF LifeCycle
prepares the data to be rendered. The binding container stores this data locally before rendering the page.
Implementations of Lifecycle should be thread-safe and use the LifecycleContext object as the place to store any per-request state they may need.
ADF Lifecycle phases:
1. initialize
This phase initializes the values of the associated request, binding container and lifecycle. The method that is used from the Interface Lifecyle for this purpose is :
initializeMethodParameters(LifecycleContext lcContext, oracle.jbo.uicli.binding.JUCtrlActionBinding actionBinding)
This method is invoked before any ControlBinding or custom method is being executed.
2. prepareModel
This phase prepares and initializes the Model. Page parameters are set and methods in the executable section of the page definition of the ADF page are executed. The interface LifeCycle method used :
prepareModel(LifecycleContext lcContext)
3. applyInput
This phase handles the request parameters. These may come by adding the request parameters in the URL or as a result of HTML form post action. A list of events is build using these request parameters. These are actually mapped to the bindings in the pageDef. This phase resolves the list of request parameters bind to attributes in the page def. This results into a list of updatedValues which is used in Update Model phase.
The interface LifeCycle method used :
buildEventList(LifecycleContext lcContext)
Builds the list of events with their possible associated action binding from the request parameters.
4. validateInput
This phase validates the list of values built in the Apply input values field with model.
5. updateModel
This phase updates data model with the list of values created in apply input values phase.
The interface LifeCycle method used :
processUpdateModel(LifecycleContext lcContext)
Update the data model with values submitted in the request.
6. validateModelUpdates
This phase validates the Updates in the previous phase by calling the associated lifecycle's binding container .
The interface LifeCycle method used :
validateModelUpdates(LifecycleContext lcContext)
Forces model-level validation to occur.
7. Process Component Updates
This phase handles any events in the list built during the apply input values phase. Named events as well as all the events tied to the databindings created in the pagdef are handled in this phase.
The interface LifeCycle method used :
processComponentEvents(LifecycleContext lcContext)
Handle any events in the action binding list previously built in processUpdateModel using the buildEventList method.
8. Metadata Commit
This phase commits the runtime metadata changes to the model. This phase is always executed before prepare render phase.
9. Prepare Render
This is the final phase where page is sent for rendering. prepareRender event is sent to all the registered listeners. This notification signals bindings to prepare or process the data for rendering. Binding container is also refreshed. This helps
in updating any changes that happened during validation phases.
References :
- Lifecycle (Oracle Fusion Middleware Java API reference for Oracle ADF Lifecycle)
- Phases in ADF LifeCycle
Saturday, July 16, 2011
What are ADF business components and which component provides transaction management?
A challenge every Java developer developing applications using data from a database faces is mapping Java objects to relational tables, managing transactions and locking, and ensuring adequate performance. There are many frameworks that help us handle this, without us needing to build everything from scratch. The open source community has produced a large number of more or less complete and robust frameworks for working with databases and Java objects. Oracle's solution is the Oracle Application Development Framework Business Components.
The main components of the ADF Model layer are:
1. The Entity objects or EO's
2. The View objects or VO's and
3. Entity Association's
4. View Object ViewLinks
5. The Application modules or AM's
6. The Business Component Tester or AM tester
The EO/VO is similar to Object relational mapping elements.
So, in essence, EO/VO provide a standard way of interacting with database tables and serve as the data model source.
The Entity Object
An EO represents a table in simple terms. It defines the table's attributes, the data types, validation on the data, the primary keys and the entire business logic that needs to be defined for pushing data into the target table.
The View Object
The view object can be based on EO's, which are similar to SQL queries used to extract data, or it can be programatically populated, or with a static list.
However VO's based on EO's are most used option. While a few validations can be done even at the VO level, it's better to have business logic on the EO's as this will help provide a central point for all VO's dependent on them.
Associations and Viewlinks
They define the join or the link among EO's and VO's. Associations defines link between EO's. They can be considered as PrimaryKey/ForeignKey relationships between tables. They define the Join conditions.
A viewlink defines the link between VO's and can be based on an association or on attributes.
The Application Module
The application module packages the VO's and serves as the data control.The AM creates and manages the database transaction for ADF Model layer. It is the Application Module that exposes the data needed by the client. So, for an end user, the interaction and transactional capabilities are provided by the application module.
The Business Component Tester
The most used component of the model layer is the tester. It can be run to check the data model that is implemented. This serves as the first line of defense to see if data is exposed as desired, without the need to create a UI.
The main components of the ADF Model layer are:
1. The Entity objects or EO's
2. The View objects or VO's and
3. Entity Association's
4. View Object ViewLinks
5. The Application modules or AM's
6. The Business Component Tester or AM tester
The EO/VO is similar to Object relational mapping elements.
So, in essence, EO/VO provide a standard way of interacting with database tables and serve as the data model source.
The Entity Object
An EO represents a table in simple terms. It defines the table's attributes, the data types, validation on the data, the primary keys and the entire business logic that needs to be defined for pushing data into the target table.
The View Object
The view object can be based on EO's, which are similar to SQL queries used to extract data, or it can be programatically populated, or with a static list.
However VO's based on EO's are most used option. While a few validations can be done even at the VO level, it's better to have business logic on the EO's as this will help provide a central point for all VO's dependent on them.
Associations and Viewlinks
They define the join or the link among EO's and VO's. Associations defines link between EO's. They can be considered as PrimaryKey/ForeignKey relationships between tables. They define the Join conditions.
A viewlink defines the link between VO's and can be based on an association or on attributes.
The Application Module
The application module packages the VO's and serves as the data control.The AM creates and manages the database transaction for ADF Model layer. It is the Application Module that exposes the data needed by the client. So, for an end user, the interaction and transactional capabilities are provided by the application module.
The Business Component Tester
The most used component of the model layer is the tester. It can be run to check the data model that is implemented. This serves as the first line of defense to see if data is exposed as desired, without the need to create a UI.
Thursday, June 16, 2011
If you hit oracle.security.jps.JpsRuntimeException: Cannot read from policy store.
When trying to start your integrated weblogic server, if you come across the following error :-
Solution:-
This issue mostly occurs due to a corruption in the jazn-data.xml file. You could delete the jazn-data.xml file under the DefaultDomain directory or delete the 'DefaultDomain' directory under the system directory inside your view. This will create the domain afresh the next time you start your WLS.
oracle.security.jps.JpsRuntimeException: Cannot read from policy store.
at oracle.security.jps.internal.policystore.xml.XmlPolicyStore.buildFromFile(XmlPolicyStore.java:425)
at oracle.security.jps.internal.policystore.xml.XmlPolicyStore.(XmlPolicyStore.java:224)
...
Caused by: oracle.security.jps.JpsRuntimeException: javax.xml.stream.XMLStreamException: End Document reached prematurely.
at oracle.security.jps.internal.core.datastore.xml.XmlDataStoreParser.getDataStoreEntryStax
(XmlDataStoreParser.java:166)
...
... 28 more
...
weblogic.security.SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag -Djava.security.debug=jpspolicy to get more information. Error message:
oracle.security.jps.JpsException: [PolicyUtil] Exception while getting default policy Provider
at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadOPSSPolicy
(CommonSecurityServiceManagerDelegateImpl.java:1398)
...
Caused By: oracle.security.jps.JpsRuntimeException: oracle.security.jps.JpsException: [PolicyUtil] Exception while getting default policy Provider
at oracle.security.jps.internal.policystore.PolicyDelegationController.(PolicyDelegationController.java:291)
...
Caused By: java.security.PrivilegedActionException: oracle.security.jps.JpsException: [PolicyUtil] Unable to obtain default JPS Context!
at java.security.AccessController.doPrivileged(Native Method)
...
Caused By: oracle.security.jps.JpsRuntimeException: Cannot read from policy store.
at oracle.security.jps.internal.policystore.xml.XmlPolicyStore.buildFromFile(XmlPolicyStore.java:42
Solution:-
This issue mostly occurs due to a corruption in the jazn-data.xml file. You could delete the jazn-data.xml file under the DefaultDomain directory or delete the 'DefaultDomain' directory under the system
Saturday, May 21, 2011
oracle.jbo.attributeloadexception: JBO-27022
Problem scenario :
I was in the process of replacing a particular table in the database with a new table (table name and attribute names changed). Correspondingly this involved creating new Entity Object, View Object, Entity Associations and View Object links. This meant replacing the old associations that are present in any of the VOs with the new ones.
As part of this, all required attributes from the EO need to be shuttled properly to be present as part of the VO. The catch here is, if the EO has any transient or calculated attributes, then these should not be shuttled into the VO. If you happen to do this, you are bound to hit the above exception when testing the VO:-
(oracle.jbo.AttributeLoadException) JBO-27022: Failed to load value at index 19 with java object of type java.lang.Long due to java.sql.SQLException.
Solution :
Remove the extra transient attributes (in the VO) that were added from the EO.
The VO test should now pass fine. The number of attributes in the Select clause of the VO object query and the number of attributes in the VO should potentially be the same!
The below link provides some more useful information on the same front :-
http://oracle-hack.blogspot.com/2009_05_01_archive.html
I was in the process of replacing a particular table in the database with a new table (table name and attribute names changed). Correspondingly this involved creating new Entity Object, View Object, Entity Associations and View Object links. This meant replacing the old associations that are present in any of the VOs with the new ones.
As part of this, all required attributes from the EO need to be shuttled properly to be present as part of the VO. The catch here is, if the EO has any transient or calculated attributes, then these should not be shuttled into the VO. If you happen to do this, you are bound to hit the above exception when testing the VO:-
(oracle.jbo.AttributeLoadException) JBO-27022: Failed to load value at index 19 with java object of type java.lang.Long due to java.sql.SQLException.
Solution :
Remove the extra transient attributes (in the VO) that were added from the EO.
The VO test should now pass fine. The number of attributes in the Select clause of the VO object query and the number of attributes in the VO should potentially be the same!
The below link provides some more useful information on the same front :-
http://oracle-hack.blogspot.com/2009_05_01_archive.html
Subscribe to:
Posts (Atom)