Thursday 23 October 2008

Oracle IAS 10g 10.1.3.x Mapping j2ee security roles to OID groups

Today I feel like I have touched down the deepest bottom of applied j2ee. I have spend two hours trying to figure out why mapping of j2ee application roles -- defined in `/META-INF/jazn-data.xml -- to Internet directory groups did not work and all it required was just to restart the OC4J instance. And although I knew the peeps in a Jeep joke, it took me two hours to finally get out and back in again, i.e. do the restart and get over with it.

To be honest, I have always wanted to do that simply by matching j2ee roles and OID groups and then use something as simple as my UserInfo bean to determine allowed user actions. The truth of the matter is that until today I always gave it up after running into the 403 Forbidden reply from Apache popping out after accessing the application..

Anyway, enough with grumbling, my advice to anyone interested in performing the same is: Just when you think you 've finished changing the applications security provider, setting up mappings and deploying the application do a final restart to the instance.

Wednesday 15 October 2008

Oracle ADF: Verifying Master-Detail relationships and throwing exception on "beforeCommit()" events

I have found no other way to validate master detail hierarchies, than using theEntityImpl.beforeCommit(TransactionEvent transactionEvent). Writing a validateEntity() function can only prove useful when examining the fields of the current record. There are cases however where you need to verify that the entire tree is correct. Consider for instance a cases where you need to verify that all items included in an order are eligible for seeding to the user's dispatch address. For cases like this you need to examine your data just before committing and the beforeCommit() does just that.

During before commit you can practically traverse your entire M/D tree using association accessors and verify that everything meets you business rules.

If anything fails to validate then raising a JboException will prevent the actual commit and the exception error message will appear on your tag in your jspx page. There is however only one small catch:

Unless you modify your application module configuration and set the jbo.txn.handleafterpostexc to true, all exceptions thrown inside the afterCommit() method result in a roll-back which completely destroys the data hierarchy just build. As Steve Muench puts it,

When this flag is true, the framework will take an in-memory snapshot of the pending state of the application module, and then use this snapshot to reinstate that same pending state in case any of the beforeCommit() methods fail with an exception. If everything goes successfully with no errors, the in-memory snapshot is not used and will just get garbage collected.

To change the jbo.txn.handleafterpostexc parameter, right click on your application module inside the application navigator, then select Configurations... from the pop-up menu, click the Edit button from the resulting dialog box and you are there.