 |
Monday, April 04, 2005 |
Over on OTN, Sashi asks how it's possible in a JDeveloper 9.0.4 BC4J/Struts application to display an error page that shows that the database is down. I cobbled together example #32 (JDev 9.0.3/9.0.4 BC4J/JSP RequestProcessor to Show Error Page for Down Database) on my not yet documented examples page to show one way to do it. It relies on a custom subclass of the BC4JRequestProcessor to catch the ApplicationPoolException raised earlier in the Struts request processor lifecycle, and then later in the lifecycle throw the exception as part of the processActionPerform() step, so that Struts' declarative exception handling will work as expected.
10:20:52 PM 
|
|
Over in a thread on the OTN forum, Markus asks a great question about the difference between top-level and nested application modules with regard to drag and drop data-binding from the Data Control palette...
I hopefully clarified this issue a bit with my follow-up posting...
Any ADF Application Module can be both a top-level service, as well as nested as a reusable component inside another application module depending on how you need to use it. For the sake of argumet, let's call our two application modules AM1 and AM2.
If you nest/reuse an instance of AM2 inside of AM1, it does not prevent AM2 from also being used on its own as a top-level ("root") application module. From the ADF data binding point of view, a top-level application module corresponds to a data control, its own transaction and EO caches, and its own application module pool for AM instances of that type. In contrast, nested application modules are simply a part of the implementation of the AM that includes them and don't have their own data control, their own transaction, or their own application module pool.
In my example above, if you use both AM1 and AM2 as data controls via drag and drop data binding, then the runtime behavior depends on which AM2 in the Data Control palette you drop. The Data Control palette will present both AM1 and AM2 as top-level data controls, but it will also present AM2 as a nested *child* node of the AM1 application module in which is it embedded. If you drop something from the top-level AM2 in the data control palette, it will create a data control for it and it will have its own AM2 application module pool. If instead you drop something from the AM2 node that is nested inside of the AM1 (top-level) node in the palette, it will not create a separate data control for AM2.
So, to your questions...
Why does the Data Control Palette provide nested AMs as top level AMs?
All AM's show up as top-level data controls in the data control palette at present. Nested AM's show up indented inside their containing AM in the palette. Since the same AM can be used both ways, they both show up.
I agree it could lead to user confusion, perhaps rather than automatically publishing all application modules as data controls, a separate "Create Data Control" step should be required so the developer would only publish the ones (s)he wants to be top-level data controls?
The NestedAM depends on the RootAM. Why can it act as independent AM when using the top level node "NestedAM"?
In general a nested AM does not depend on the AM that embeds a nested instance of it. Rather, the reverse is true. A containing, nesting AM depends on the AM instance it contains but not vice versa.
How many instances of the NestedAM exist when I use both 'versions' (top level node and childnode) in my bindings?
If you use both, then you'll have one instance that is a top-level AM and pooled as explained above, and another instance that is just an embedded part of the containing AM whenever it is used.
2:19:28 PM
|
|
© Copyright 2008 Steve Muench.
|
|
