ADF BC Application Module Data Control Hints for JDeveloper 11g R2 ADF Libraries

I got a question from blog reader, based on my previous post - How To Reduce Database Connections and Reuse ViewController Layer. This post is based on ADF library dependencies with ADF BC objects - library is not imported directly into project, but is accessed through proxy library with implemented root Application Module - to reduce opened database connections. However, same application fails to work on design time in JDeveloper 11g R2 (latest release from this week) - IDE wizard returns error about missing Data Control objects. It works on runtime though, means there are no issues with ADF runtime, its something with IDE. However, I would not claim this as IDE bug, I believe that IDE applies best practice approach for how we should consume ADF libraries. There are few hints to keep in mind, when working with latest JDev release and consuming ADF libraries with ADF BC objects (specifically Application Modules) inside. This applies only to those cases, when you are reusing Application Modules from ADF Libraries.

Download sample application - ADFBCLibsSharedApp.zip. This sample contains three ADF applications developed with JDev 11g R2 - SharedLibsApp (ADF BC reusable components), ADFBCLibsImportsApp (demo how to consume ADF BC libs on ViewController), ADFBCLibsImportsModelApp (demo how to consume ADF BC libs on Model).

SharedLibsApp contains one project with reusable ADF BC objects and Application Module - LibModule, both packaged into reusable ADF library. This library is not referenced directly from other projects, but through RootLibModule AM (another project), which is also compiled into ADF library (same scenario as from blog mentioned above):

Root module library contains root Application Module, it nests modules from another ADF libraries:

Consumer application imports root module library:

However, what happens in newest JDev release in this scenario, for example when navigating through Page Definition elements (referenced from imported nested library through root module) - Data Control iterator is not found (this error is reported in the loop and practically kills JDev, you need restart). This happen for ADF apps implemented with previous JDev versions, its not current IDE bug:

From project structure we can see, there is Library Dependency file - it points to these libraries not imported directly, but referenced from directly imported ones (in our case it points to adflibModelLib):

If we open Data Control tab and try to expand nested module, it also fails to be loaded:

This clearly indicates that, ADF Library dependency fails to bring dependent library into context, its why we can't see it through Data Control.

In order to fix this, you only need to add required library dependency directly:

Now restart JDeveloper - good news JDev 11g R2 restarts really fast, so you don't need to wait that much as before.

No ADF Library dependency file available anymore:

Data Control is constructed correctly this time:

Page Definition objects are loaded correctly as well and are accessible:

Page is loaded on runtime as well:

This case is clear now, lets explore one more scenario - ADF library with ADF BC imports into Model project. Let say our ADF library contains two Application Modules:

Library is imported into Model project and both Data Control instances are appearing correctly:

However, once we enable ADF BC support for local Model project:

Data Control instances are disappearing:

If we double check imported objects, both AM's are present:

It may look wrong for you, but I would assume its correct behavior in JDev 11g R2, even same was working in previous release. If we import AM instances into ADF BC Model project, it would not be a best practice to reference different AM's separately through Data Control - lots of database connections would be opened. Instead of exposing imported AM instances directly through Data Control, we can nest them into local AM:

Now both imported AM's are accesible from Data Control through root local AM:

If you dont want badly to nest imported AM instances into local AM, there is still a trick you can apply - but I don't recommend it. You can open Model.jpx file and add imported AM instance there manually:

However, this would be a bad practice - Model.jpx gets regenerated quite often automatically and you will loose your manual changes. And as I already explained, its good to nest imported AM's, to prevent large number of open database connections. When Model.jpx is changed manually, imported AM instance becomes visible - until Model.jpx is not regenerated by JDev: