Monday, 25 January 2010

JBO-34010 + JBO-25058: Master ADF applications, Bounded Task Flow sub-applications and ADF Libraries

(JDev 11g 11.1.1.2.0)

Under JDev 11g when you start playing with importing Bounded Task Flows (BTF) through ADF Libraries into a master ADF application, you're likely to start encountering the errors JBO-34010 and JBO-25058. This post discusses why these errors occur in context of ADF Libraries, and composite master ADF application comprised of 1 or more BTF sub-applications.

JBO-34010

JBO-34010: The "view/DataBindings.cpx" descriptor appears in the application classpath more than once

This error can occur because the ADF runtime demands that if an application includes multiple DataBindings.cpx files they must live in different Java packages. We've hit this when we've created a single master ADF application that loads one or more Bounded Task Flow sub-applications via the ADF Libraries feature, where each application has dropped the created DataBindings.cpx file in the default ViewController package "view".

You have two options in solving this issue:

The first option is to avoid the issue in the first place: when creating your ADF applications, be they a master application or BTF application, ensure to change the default package of the ViewController project via the Project Properties -> Project Source Paths -> Default Package option, or when you create the application change the package options in the Create Application wizard.

The second option is to make a retrospective change by selecting the view package in the ViewController project of each of your applications and refactor the package name. Be warned in the JDev 11g PS1 build 5536 I've had varying degrees of success with this option (read: lots of failures). Sometimes the refactor option messes up the new package name, other times JDev refuses to forgot the old view/DataBindings.cpx files until you Clean All under the Build menu on all the applications. Sometimes I have to carefully hand craft the fix by dropping out of JDeveloper and changing the files manually. I'm probably doing something wrong here, but it seems a bit of a mess. Best go for the proactive solution to save heartache.

JBO-25058

(For readers Googling in on this post/error code, please note this error can occur for other reasons beyond the scenario described in this post. I refer you to Andrejus Baranovskis's post and otherwise undertaking a careful search for further useful resources.)

oracle.jbo.NoDefException: JBO-25058: Definition EventNo of type Attribute is not found in EventNo.

Note EventNo is specific to my demo application, you'll have other attribute names here.

This error can occur where within each application, they refer to the same Application Module Data Control name, typically AppModuleDataControl created by default by JDeveloper. This name must be unique across DataBindings.cpx files, which can be located in your master application and separate BTF applications.

The first option is to avoid this issue in the first place: the Data Control name when created in the DataBindings.cpx file by default uses the Model project's Application Module name with suffix DataControl. Thus if your AM is called AppModule, the default name for the Data Control is AppModuleDataControl. Instead when creating your AppModules in an ADF BC Model project you give them a unique name, say ProcurementAppModule or EnrolmentServices, those names will be carried to the creation of the DataBindings.cpx as ProcurementAppModuleDataControl and EntrolmentServiceDataControl respectively. As such collisions in the Data Control names are less likely to occur.

The second option is to make a retrospective change by changing the Data Control name in each DataBindings.cpx file. However be warned that you must also update any pageDef file to then refer the new Data Control name too.


With regards to both issues above, as there are proactive solutions to avoid the problems in the first place, by ensuring a unique ViewController package name and a unique Application Module name in the Model project, it's recommended these become coding standards adopted by your organisation.

1 comment:

Dave said...

thank you SOO much for the insight for this problem :-)