Metamorphosis from Forms to Java: a tech lead's perspective (paper)

METAMORPHOSIS FROM FORMS TO JAVA: A TECHNICAL
LEAD'S PERSPECTIVE
Michael A. Fons, Rohmann Joint Venture/Graebel

Many thanks to RMOUG and the tireless volunteers that make it continue to happen year after year…

Introduction

My hope in producing this paper and the corresponding presentation was to help somebody who was going through what I
was (and still am) going through. As Oracle has attempted to distance itself from “old school” client-server-esque tools such
as Oracle Forms, Oracle Reports and perhaps even PL/SQL, guys like me and companies that invested in these old-school
technologies have to come to grips with reality: we are just going to have to move on.

For many this means learning Java, Portal, JDeveloper, JHeadstart, BPEL, or whatever else is appropriate. I figured that as I
go through my “personal” transition of this nature and as I work for companies that are also going through it I would simply
try to record things that I thought would be helpful to anybody else transitioning in the same way. So here is the paper. I
hope it helps you.

Reasons for transition

Technology issues
A company must look at many issues related to technology and technologists when considering what technology to use.
Is Oracle planning on de-support of Forms and Reports? Not at this point, as Oracle announced a few months ago, according
to Peter Koletzke. I feel though that some day it is probably that Oracle will officially turn its nose up at Forms and maybe
Reports, too. (Although Oracle Reports is a stellar performer on the web, Oracle has other ideas, judging from a demo I saw,
to replace Oracle Reports with other tools involving using MS Word. How ironic.)
On the people side experts, in old technology harder to find for reasonable fee…or at all. Technologists must worry about
becoming obsolescent the same way that so many professionals must stay current with whatever their field might come up
with. As people learn new things they naturally want to use them in their daily lives to re-enforce the concepts in their mind
or because the idea seems particularly apropos to whatever they are working on at the moment. There are some people,
however, that do not march to this drummer. Instead they cling to past technologies and spend all their professional efforts
supporting old technologies. The companies using the old technologies are grateful, but fear or whatever eventually routes
out these folks until somehow there is a lagging minority left supporting the old tools. They must live in a Winnebago and
drive from place to place to survive (that is how my nightmare goes anyway). Most companies do not want to get involved in
this sort of non-sense so: they move on technologically, too.
For their own nightmare-ish reasons, good people may leave a company if they cannot stay marketable; these people may
look at where different markets are going; some industry experts agreed in a recent conversation, for instance, that industry

www.rmoug.org RMOUG Training Days 2007

Metamorphosis from Forms to Java … Fons

and Oracle shops are going toward Java lately to be sure, although not always to ADF, but some other configuration –
perhaps still using JDeveloper though.
As technology progresses there will be companies formed all along the business cycle to support these transitions. For
example there are third-party vendors which can create J2EE/EE5 applications from Forms web applications.

Customer dissatisfaction with current products
Why wouldn’t someone love Oracle Forms applications? You can build anything using Forms, so what’s the problem?
• Forms by default leans a developer toward the use of enter query mode because it is easy to implement – but some
end users find this concept non-intuitive. Those users often prefer entering some search criterion and then pressing
Find.
• Some think there are some pieces missing from Forms GUI palette. While it is possible to implement just about any
widget in Form it is not necessarily “easy” to do so always.
• Forms is based on a set of complex trigger interaction which can be difficult to predict and troubleshoot. Triggers
and fixes affect other functionality, and fixes you might expect to be intuitive and simple require special knowledge
to implement.
• Without adequate automation, keeping JInitiator and certificates up to date can be a pain for the user, especially for
internet apps – causing users to loath use of the system at hand.
So often we find companies, end-users, and developers clamoring for change in this arena. Promises start to surface related
to new technologies which will solve any or all of these issues.

General managerial ideas
It is very easy to want to convert to another technology. Getting managerial buy-in is a different matter altogether.

If decision to go to Java (or something) is still being made the GM would usually ask…
• If the old technology works why fix it?
• We have got too much else to do; why bother? It will just put us even further behind schedule.
• Or how about, quot;Is this just another 'cool technology' or Oracle sales gimmick?”

But presuming you already have buy-in they will ask questions like…
• how do we get our people trained and keep up with current work?
• how steep is the learning curve?
• how fast can we be productive again?

Consider the following in trying to answer these questions. In order to keep up with current work some decisions must be
made regarding what approach you will take to converting the forms and reports. You may want to consider what your
current work-load is like. Also, do you have programmers that can learn by doing? If you have buy-in from the top one
approach is to focus on the soon-to-be-legacy forms/reports system for a year. For that year focus on stabilizing the
application and accept no new development. For any new development or major business rule changes try like the dickens to
get it put off for a year. After that year do no more non-emergency work on the old system. Do all work on the new system
using all your programmer resources. So the users are using the legacy and any change requests they have are being
implemented as part of the new system. Then the new system goes on line when it is thoroughly tested and bug free (ha ha
ha). This wholesale approach was used by the Naval Academy not too long ago on a major computer system it has.

Another approach is to convert piece meal at first. First do some pilot project which converts some part of the system.
Perhaps you will have co-existent forms and java code. As your developers come on-line better and better and your new
software development infrastructure comes on-line you will be able to manipulate larger and larger portions of your system to
fit the new paradigms. If your system is divided into organization specific applications you can eventually work on
converting an application at a time. This is the approach our organization is taking.



With these two approaches the answer to the “how quickly will my people be productive again” is slightly different. With
the wholesale approach you end up being super-productive for a year then not productive at all on the legacy system and
super-productive on the new system. But it is all sort of theoretical productivity until you do the massive cut-over. That is
somewhat risky.

With the piece-meal approach the IT department is continuously productive but slightly less attentive possibly to the end-
users needs since they are also trying to factor in technology learning and pilot projects on top of that. But at least these
people get to doing something that someone will truly use faster than the wholesale approach…

Either way, do something!
This will get you started and combat feeling overwhelmed during the conversion process. Here are some books I have used
for research for this paper which I would encourage you to look at (note that some of these books are meant to be read page
by page and some are to be used as reference manuals):
• Oracle ADF developers Guide for forms and PL/SQL developers: B25947_01, or other such books from the Oracle
Technet ADF homepage.
• Oracle Containers for J2EE: Configuration and Administration Guide, 10g Release 2 (10.1.3) – Part number:
B14432-01 (Note: OC4J is a good lightweight container which is worthy of your study as you go forward in your
conversion process.)
• From NetLibrary site: Enterprise JavaBeans Java Series (Sebastopol, Calif.) Author: , Monson-Haefel, Richard.
Publication: , Sebastopol, CA O'Reilly and Associates, 1999. eBook ISBN: , 1565929519
• Oracle JDeveloper 10g for Forms & PL/SQL Developers, by Peter Koletzke and Duncan Mills, McGraw Hill, 2006.
ISBN-13: 978-0-07-225960-5
• Oracle JDeveloper 10g Handbook, by Dr. Avrom Roy-Faderman, Peter Koletzke, and Dr. Paul Dorsey, McGraw
Hill, 2004, isbn: 0-07-225583-8
• http://www.oracle.com/technology/pub/articles/smiley-as10gr3-install.html -- this is Installing Oracle Application
Server 10g Release 3 on Linux x86
• JDev help is good too; for example for help on skins and templates enter “skins” on a help search and find the topic
of “working with skins in ADF faces”.
• OTN is always good; for example, look in the JSF section of the otn.oracle.com page to see details on the ADF
faces tags available.
• You can find out about JSF EL and many other topics on http://java.sun.com/J2EE/1.4/docs/tutorial/doc/
• Whatever else you can find…

Do demos, join list servers, buy/borrow books, Google code, work with other developers, attend conferences like RMOUG,
train other people in your group less knowledgeable than you on the subject (to help them and reinforce concepts for you as
well). If possible, interleave working with JDeveloper/ADF/JSF with actually reading and learning about it. I think you need
both sides to actually continue learning and stay interested and not get depressed or bored. Try not to let yourself get too
down about what you do or don’t know along the way. Remember that you are learning and that can be hard. If someone
learns something before you try to see that as an opportunity to learn from them and not an indication that you are dumb.
ALLOW YOURSELF AND YOUR TEAM ENOUGH TIME FOR THE LEARNING CURVE DURING THIS PROCESS
especially the more advanced topics. Later chapters to most manuals are really impenetrable, especially if you just skip to
them without proper background. Probably you will need enough time to work into the advanced concepts chapters and learn
the background first.

Here are a couple more thoughts on learning tools: Try to get versions and self-help books that are very recent and then dive
in before they become antiquated. Also, if you are ever confused on a topic search multiple sources on the same topic until
you get enough perspectives to be able to operate.

If you don’t know Java, try to learn it somewhat before you work with Oracle’s ADF developer’s Guide for forms and
PL/SQL developers. This book expects that you know somewhat what is going on with the java language. If you do not do



this you may get lost or confused. There is a fair amount of java for a book that is supposed to be geared toward forms and
PL/SQL developers; and yet the book is usually stepwise and complete in its approach to the subject of learning to code in
the ADF.
The reason for the amount of Java in this book is that the ADF is really great; but compared to some other frameworks, ADF
has not been around that long; so there are still some things that really need automating. Eventually the ADF developers will
get around to fixing these things, but they just have not yet because there are only so many hours in a day…which means that
you will need to go in and fix things up your self if you cannot wait…which means they need to spend more time about
extending the default classes that are a part of ADF.
Additionally the following things may be confusing that they mention in this developer’s Guide: when you create java code
you create classes. When classes are running they are called objects. When these objects are “instantiated” they are called
instances (c.f., “new” keyword in java). In this manual instances are sometimes referred to as objects and so are classes. It is
just important to be aware of this distinction to avoid too much confusion.
The way they refer to java interfaces in ADF is perhaps confusing for someone just learning Java. Interfaces are a construct
in java that contains no code. And yet they have a practice of at time talking about them as if they are interchangeable. Be
careful you at least know what an interface is and what it is generally used for.
Training Courses
I checked out what training for our group might cost for ADF and Java. The two companies that I checked out had costs that
were comparable. There were many things that went into pricing for these two companies, and many ways they would allow
you to cut corners depending on how much you had to spend. For example one company offered that if we could put them
up in the houses our management (since they would be flying in) that they would not charge for room. For another example,
if your organization is with the government, they may give you GSA rates. If they offer GSA rates to the government,
however, they probably will not be able to go lower than these rates even if you are not with the government or they may end
up owing the government money.

It looked as though in the two places I checked out that a group of 10 people could be trained in Java and JDeveloper for
around $1,000 per day. The entire package a training group offers may include travel expenses and incidentals (or not). It
may also include mentoring packages to help you follow up your training.

New Blood
Bring people into organization that have experience and enthusiasm for helping you get where you want to be. These people
should be…
• Self-motivated
• Comfortable with Changing Technology
• People who can build a pilot, then take it to management and convince them to go all the way with that.
• People who are capable and really willing to share their knowledge with those who are truly interested in learning
and willing to put in the time to learn.

Pilot Projects
Create pilot projects in the new technology as soon as possible in parallel with your current technology for something you
already need done and have to do anyway. This will take lots of work. Here are a couple of approaches to doing pilot
projects:
• Redo things exactly as they are now only in the new technology.
• Redo things to be different – in order to do this you will need a post-mortem on the methodology of the current
system: what worked and what did not. For example Oracle Designer’s Forms generator likes generating forms
such that they map one-to-one with to tables; but user processes do not always map to tables. So instead of making
a form table-driven, could you not develop an application that follows the contours of the user’s processes and aids
in their completion? Surely those two contours are not the same.

Planning your architecture
Here are some ideas and questions which may help you get started planning your architecture in the new paradigms:



• Talk to the users: what do they want changed; someone will need to educate them on what is possible, otherwise
they will suggest improvements on what is currently in existence and customary for them. Do a post-mortem with
them: what is it about the current system that interferes with the way they do business now?
• Where are you going to put the business logic? If you have lots of triggers and tapi and capi and vapi and mapi what
are you going to do with it all? You may have millions of dollars invested in your PL/SQL – business logic. And
yet you may be missing out if you do not follow the standard idea of putting the business logic in java. And if you
choose to migrate your business logic from triggers to Java, will you have to maintain both layers until all your
trigger logic is replaced by Java business layer?
• ADF BC View Objects – who is going to create standard entities and views? Are they going to base them on what
views exist currently? Are they going to analyze the business processes? Are they going to be big so that lots of
people can use them? What about deciding what parameters to tie into their where clauses?
• CM environment – what are you going to store? What tool will you use? For example will you store all your entity
objects in Subversion so that all developers can use the same entities for all their projects?
• Testing – are you going to use JUnit? Are you going to test by some other means?
• Modeling – are you going to go back in to your models and redo them using use cases or some business process-
oriented modeling?
• Planning -- whatever you do, write it down so the “next guy” can stand on your shoulders and not be left hanging.
• Programming/GUI standards – what components will be available to every programmer? What pictures will you
use? What sort of navigation paradigms? What style-sheets or skins? What will the standard resolution(s) be?
What sorts of fonts will be used?

Deployment issues and Server Planning
You need a place to deploy. It is very de-motivating and unrealistic to have motivated developers deploy to their own
computer for too long. It seemed like trying to get a place to deploy touched on everybody and made them aware that they
did not have enough money, time, servers, memory, whatever to allocate. Also there was risk involved if any servers needed
sharing. Even if you want to go the virtual machine route, you need to pay for the software or at least consider the non-free
versions to see what they have to offer. That said, you are going to want to deploy somewhere. Here are some hints about
how you might go about it.

To standalone OC4J
You can download an OC4J or you can use the standalone OC4J that comes with any JDeveloper installation of late. There
are instructions in JDev help on how to deploy and where the standalone OC4J is located in the JDeveloper home. Here are
the basics of deployment for this lightweight deployment target:

You will not need to download the ADFinstaller I do not think. I think this would mostly be used in deploying to odd servers
that did not already have the right set of libraries to support the application you are deploying. If you did need it you would
use the command “java -jar runinstaller.jar ADFinstaller.properties”

(At the outset you do not need to worry about deployment descriptor alterations from the default settings.)

Highlight your ViewController project, right-click, and select new->general->deployment profile on the right-click context
menu. Use the option to create a war file (not an ear file). Specify the app name, and accept other defaults; you may want to
change the context root to something shorter in length.

Once this profile is created, right-click on this new descriptor; deploy to an ear file. It is also possible to create a connection
to your target application server that would allow you to deploy directly there without creating this ear file. But it would
probably be more portable and more instructive to you if you just used the ear file to deploy up front.

On oc4j admin deploy the ear file using two commands in succession (or do the same things with Oracle Enterprise Manager
that comes with the standalone OC4J):
java -jar $J2EE_HOME/admin.jar ormi://localhost oc4jadmin admin -deploy -file ./lib/myapp.ear -deploymentName myapp
java -jar $J2EE_HOME/admin.jar ormi://localhost oc4jadmin admin -bindWebApp myapp myapp-web default-web-site
/myapp



In fact when you use the Oracle Enterprise Manager to deploy ear files the enterprise manager uses these admin.jar
commands in the background to get its work done. This is evidenced by the output log of the enterprise manager, which
produces the same deployment output as using these admin.jar programs, and running the process manually.

During the deployment process I observed once that sometimes the deployment does not appear to work and you just need to
redeploy...then the app works. I may have done something wrong, but perhaps this is just a delicate process. Heads up to
you, dear reader, in any case.

If all this talk of ear files makes you nervous you can also create an Application Connection to your machine or whosever
machine the oc4j instance is on and deploy to that. JDev will do it all for you and you can just study JDev’s output log if you
are curious what happened.
To OAS 10.1.3. (10gAS, release 2)
I fresh installed OAS 10.1.3 in order to do some actual testing. Our normal web server was still at OAS 10g release 1
(9.0.x.x??). The install went well. I had a sysadmin who had time to get Linux installed for me. I then downloaded the .cpio
file which is used for installing OAS 10.1.3. To install this file I just followed the instructions on
http://www.oracle.com/technology/pub/articles/smiley-as10gr3-install.html which work quite well...except that the list of os
patches needed were not 100% correct. (use the list that the oracle installer gives you) Initially it alerted me I needed to
install some additional OS packages, but my sys admin took care of that for me on the Red Hat site. These instructions
reference Red Hat release 4. We were still on 3 so the packages they had listed for 4 did not fit what we were doing. After
that the install went very well.
I had an ADF app that I was playing with. So I did the deployment manually in case there were restrictions in how we did
deployments and were not allowed to use JDeveloper’s deployment-made-easy features. It deployed fine but I thought I
could test through Enterprise Manager. You can test through enterprise manager, but enterprise manager application test
button did not know anything other than the context root. After the context root you still need “…/faces/yourfrontpage.jspx”
Because I forgot that it needed “faces” in there I thought I needed to install the libraries with the ADFinstaller program. So I
wasted a lot of effort, and recorded my mistaken efforts in Appendix A of this paper in case anybody really ever *does* need
to use the ADFinstaller program on Linux. (That program worked great, by the way)

Potential issues deploying to different AS server versions
My general advice is to use 10.1.3 AS and JDeveloper versions or later for deployment. I am not too versed in the details of
doing otherwise. I know it is possible to generate a 10.1.2 AS compatible version of a JDev application using JDev 10.1.3,
because some of the people here are doing that; I just do not know how at the time of this publication.
Also I have notes that I took from one of our gurus; here are my notes (I may have gotten some things wrong here):
JDev 10.1.3 uses JVM 1.5 by default. Deploying such an application could be a problem deploying to 9ias which
does not use this JVM. Also, apparently 10.1.2 and 10.1.3 versions of the OAS require different XML files for the
ears you create. Since 10.1.2 of JDev and oas seem to use JVM 1.4 and J2EE 1.3 standard and 10.1.3 JDev and oas
use EE 5.0 that means a lot of the XML files in the ear files have a different standard format as per the standards for
J2EE 1.3 and EE 5.0. So there are differences in the way the deployment descriptors need to be adjusted for these
different kinds of deployment. You might want to set up a sandbox machine or VM software if you need to do a lot
of experimenting with different kinds of deployment sources and destinations.

For proof of some more difficulties you might run into with versions prior to 10.1.3 of the AS and JDeveloper, here is an
email showing some research that a friend of mine discovered after much blood sweat and tears; I do trust the contents of this
email for your use and abuse since I was somewhat involved while my friend was working out the details:
Peter,

We discussed this briefly last Wednesday, but I wanted to document it...

I was successful in getting my JDev 10.1.2 EDL prototype running on the OAS 9.0.4.3 install on Camis04.
I did need the ADF libraries and have included a list of the jar files installed.

JDeveloper has a help document that gives instructions for adding the ADF libs, but I found out the
hard way that it's inaccurate. Metalink recommends using JDeveloper to install the libraries by using
the Tools->ADF Runtime Installer. This requires that JDev be installed on the same machine that OAS is
installed (or samba mounting the ORACLE_HOME dir remotely). I installed JDev and ran the utility. It



installs the 10.1.2 version jars and, where necessary, archives existing older version jars to a
directory under ORACLE_HOME (BC4JAR.9.0.4.14.32) which can then be used (via JDev) to restore the
original jars if necessary. Real slick as long as you use JDeveloper.

I did have to add two additional jar files which the server complained about when I tried to run my
specific application:

./BC4J/jlib/bc4jdatum.jar
./ord/jlib/ordim11.jar

I also added the following lines to the /opt/oracle/J2EE_904/J2EE/home/config/application.xml file to
support those files:

<library path=quot;../../../BC4J/jlibquot;/>
<library path=quot;../../../ord/jlib/ordim11.jarquot;/>

After deploying the JSP version of the app, I was able to deploy and run the UIX version and that one
is out there now. I will change the link on the DF web page <http://some.computer.com:8888/df/> to
point to the installation on <somecomputername>. I also have a link to the EM console from that page.
The password is quot;xxxxxquot;.

Thanks for the help with this. I will continue to develop and test on Camis04. I will also set up a
meeting with Don V about JDev/OAS versions, authentication, deployment, etc. per our discussion with
Scott of last Tuesday.

Dave

Files needed to run 10.1.2 JDev apps on OAS 9.0.4.3

./BC4J/lib/collections.jar
./BC4J/lib/bc4jdomorcl.jar
./BC4J/lib/adfm.jar
./BC4J/lib/adfmweb.jar
./BC4J/lib/bc4jimdomains.jar
./BC4J/lib/bc4jmt.jar
./BC4J/lib/bc4jct.jar
./BC4J/lib/bc4jmtejb.jar
./BC4J/lib/bc4jctejb.jar
./BC4J/lib/adfmtl.jar

./BC4J/jlib/bc4jdomgnrc.jar
./BC4J/jlib/adfjclient.jar
./BC4J/jlib/bc4jdatum.jar*

./ord/jlib/ordim.jar
./ord/jlib/ordhttp.jar
./ord/jlib/ordim11.jar*

./jlib/ojmisc.jar
./jlib/jdev-cm.jar

./J2EE/home/applications/BC4J.ear (extracted to BC4J dir in the same applications dir)

The technologies

It is important to understand some of the differences between the technologies and environment that you are moving away
from as it compares to that towards which you are moving:

From: forms/reports/PL-SQL/designer
Using forms/reports/designer/Headstart (some would argue) eliminates to need to do some up-front planning because many
of the decisions have already been made for you. For example you can use forms to query things up a variety of ways, but if
you just use form’s out of the box default behavior, or designer/Headstarts default behavior for generating forms you get
quite a lot of functionality in a standard format. So if you were not too creative you could simply get things going and have
standards automatically by using these tools in their default formats.



When converting forms modules in designer any .plls that you have created will need to be rewritten. Any application logic
associated with tables that would normally go into the TAPI will need to be rewritten in business logic (BC or Toplink).
Also any module level custom application PL/SQL code you wrote in modules will need to be converted to java. In
conversion situations this transfer of these programmatic items represents a large amount of effort in a conversion process.
In a forms conversion a single form can have many tabs. Given that the forms are web-based you do not want to put that
much on a page. Maybe one parent-child relationship. So one form will sometimes map to many pages.

To: JDeveloper/ADF/J2EE
With this platform you have many more decisions to make. Much of what you learn is at a lower level. You have to spend
more time learning how the pieces fit together. On the other hand if you learn smaller components you will not be as locked
into a monolithic solution or IDE; you will simply know about the various components and be able to construct what you
need no matter where you are or what you are doing.

Developing – general concepts
In the JDev IDE there is lots of drag-and-drop; but what do you drag where? The intuition for this comes from more intimate
knowledge about how the applications are actually constructed – so keep studying the manuals and experimenting, and the
familiarity will come; for example, it is probably best to drag a collection from the data control palette (if your application
contains a model project) and then specify what kind of component you want to use from the context menu that pops up
rather than to drag a component from the component palette, then try to hook it up with the right collection later on. (This is
generally speaking; of course there will be exceptions to this rule. One advantage to dragging a data control is that your
iterators are lined up and bound as a result of this drag-and-drop.)

Another example of knowing what to drop where comes on a prompt you get with you drag and drop some ADF-faces
components. JDev automatically warns you against putting the component into the page without a surrounding form
component/element to go with it. It is hard to know when to follow this advice because the correct answer to that question
depends on the component. For example there is a component (switcher?) that I ran across which must have a surrounding
form or you will get a runtime error. On the other hand there is a menu item component that should nest in a menu bar
component that should not have a form or the vertical separator bar between the menu items will not be there. So: same
advice, two different correct answers.

As you learn and proceed with experimenting and working through manuals do everything over and over until you are
satisfied. If you do not understand something do not kid yourself; probably other concepts will be based upon that one you
are not getting. Dig in and figure that thing out…whatever it is.

Learn the names of the different editors so that you know what people are referring to in manuals. For example there is an
editor for every type of model object, another for model project configuration, one for the web.XML file, another for security
settings, and many others – each of which require a slightly different technique and bit of knowledge to know where to go,
what to click, what pane to visit, what to right-click and so on. The quicker you learn these the sooner you can focus on what
the manuals are trying to tell you what to do.

One concept which is very appropriate is that of the MVC: Model-View-Controller. If you do not already know what this
means or where this concept came from, then you would do well to learn. Basically the Model is the Database or Data side
of a program that is using this structure. The View is the part you see, or the GUI part. The Controller is the part that helps
the user get from one part of an application to another. It is more complex than all this, but this basic definition may help you
get off the ground until you find a more complete definition.

What follows are some basic concepts and some highlights about the model layer and the view/controller layers that may
help you in dealing with these different parts of the ADF in JDeveloper.

MODEL:
Like setting up triggers and database-level business logic the Oracle developers Guide spends the first 9 chapters talking
exclusively about the Model part of the programs that they would have you build using ADF. So it is important. It is
foundational…literally. Especially since you probably have an Oracle background. I imagine it is intuitive to expect that an
Oracle developer thinks of the Database as foundational to their database application…same goes for the Model part of an
ADF application.



In JDeveloper/ADF the model side is made up of entities, views, and application modules. These three items are concepts,
but also they all are classes; so here goes another quick definition of these model parts: entities are like tables (table rows,
actually). If you have done ERD’s before in a little depth this should not be a foreign concept to you. Views are like queries
against the tables. Application modules are like, uh, something that bundles all the entities and views together so you can
move it around as a lump. (Entities are really only needed if you plan on doing updates, inserts or deletes against your tables.
If you are entities make these basic operations much simpler than they would be without them.)

If you like thinking about things in layers you can think of first databases on the bottom, then entities on top of the databases,
then views on top of entities, then application modules which collects instances of view and entity objects.

The application module class is a good place to do custom coding in many cases. For example, if there is any code that you
want to do every time a new person starts a session on an application if would be best if you overrode a method called
prepareSession inside of ApplicationModuleImpl class (your custom version that is.) Here is how you would add such an
overridden method to your custom version of the application module class: In the Java node of the application module editor
you need to indicate that you want a java class generated to allow you to inherit and modify the functionality of an
application module. In order to override the prepareSession function you need to edit the java file that is generated when you
turn java customization on for your application module. This java file will have the same name as your application module
but will add “Impl” to the end of the name. Edit this java file. In the code editor for this file go into the Sources menu in the
JDeveloper main menu. Under this there is an Override Methods… menu sub-option. Click on this. You will see a list of
methods in the ApplicationModuleImpl class that you can override. There are two prepareSession methods in this list.
Choose the top one (the one with the key next to it…not the one with the lock). Click OK. This will add a basic function to
your app modules custom java file. You can then add code to it to do things like change the where clauses of view object
queries to limit what people can see based on their log in id.

As I said earlier in the paper you need to think seriously about you company’s entity layer and view layer and plan how your
model layer is going to improve reusability on an enterprise level. Since Entities generally map one-to-one with tables you
do not have to do much thinking to reuse entities. However when you get into custom coding you need to make sure that
your entity level business logic does not refer directly to view objects. There is a way (illustrated in the Oracle ADF
developer’s Guide) to indirectly use view objects however that is just fine. It is also interesting to note that you can share
view objects if you build them in a generic fashion. Also you can build Application modules so that they correspond to a unit
of work for a user (a “use case”) so that you can reuse application modules also. It is possible to have instances of
application modules inside of other application modules. For this reason in fact you will see references to the “root”
application module, since these can be built hierarchically.

View Objects (as Oracle calls them) can either be straight queries hitting the database, or they can be queries which hook into
Entity objects which refer to tables. In the latter case there is something called the Entity cache which incurs some overhead;
so if you are not planning on changing data you probably just need to use the views without the entities. Such views are
called read-only.

As I said just now Entity Objects actually represent a particular row in a table, not all the rows together. Entity definitions
are another object that represents a collection of the rows for a table, and serves as a placeholder for any properties that are
more appropriate to the table level than to the row level.

It is possible to link entities and views together with other entities and views by using various kinds of connectors that map to
primary key and foreign key references in the databases. If two entities are linked together with PK/FK relationships then
you can define these connections. Sometimes changing these links to be just what you want is troublesome. For example
views links are fairly simple to deal with when you use the default that maps views the same as the entities are linked.
However if you then change your mind want to create a view which used two tables. This seemed to create some problems
for the links involved. If you use the application module editor it is possible get these links straightened out to match what
you are doing, but you have to know that if you want to add a child to a view object instance on the right side of the page
then you must select the view object which is a child on the left hand side of the page in order to get the link to occur
correctly on the right hand side.

It is often useful as you create your model level components (views, entities, application modules) to put them in separate
directories or folders (called “packages” in Java parlance). The documentation says that JDeveloper supports moving



packaged objects around into sub-packages fairly easily. I personally would recommend just putting your model-level
objects in the right place to begin with rather than putting them somewhere then moving them later to some other place. I
have seen refactoring become rather messy unless you know a whole lot about the way all the different XML and java and
configuration files fit together. I have seen examples even with the latest JDev build where refactoring has resulted in cryptic
runtime errors. Also JDeveloper seems to move some objects better than others. JDeveloper has gotten a lot more complete
with its Refactoring capabilities of late though. Still though, if I can get a wizard to put my files in the right package
directory up front, then: so much the better.

It is possible when using BC wizards (especially the entities from tables wizard) and project wizards to put all entity objects
in one sub part of the package tree, the views in another, etc. on the spot. Just be sure to notice with each page of the wizard
how your package specification may need to be changed. A standard they seem to like in the ADF developer’s Guide is that
entities can be put in a “entities” sub-package, views in a “queries” sub-package and the application module can be put in the
parent directory to both of these sub-packages.

There is another part of refactoring which allows you to duplicate a file which seems safe enough. It is used in the ADF
developers’ Guide.

Sometimes when developing the model layer of your application in ADF it is helpful to be able to visualize what you are
doing to give you the bigger picture. For that you can experiment with a thing in JDeveloper called a Business Components
Diagram. For example, it is possible to drag entities and their links into view objects in the BC Diagrams; this would
represent creating a view object based on one or more tables. Also you can drag views and view links into Application
Modules in the diagrams; this would represent what queries and data entities you would need to query or change in your
application and how they are all connected together. If you drag and drop an application module that was created by a
JDeveloper wizard into the Business components diagram you may notice that they are apparent duplicate view object
instances. This automated process sometimes creates multiple instances of view objects and their view links within the
application module. This is ok; it seems to be a sort of shorthand; perhaps it is to keep link lines from proliferating within the
application module and making things really confusing. At any rate you can use whichever instance of your view objects you
find most appropriate.

One reason developers like ADF is its capabilities to deal with international deployment to different locales. It is possible to
set language/locale-specific information in a view through the view object’s control hints. When looking at the view object
editor for a view object you will see a tab for Control Hints. For example if you wanted one set of field prompts for your
English customers and one set for your French customers you could use the control hints to create language specific bundles
through these control hints that would label the fields with either English or French descriptions – depending on the bundles.

VIEW/CONTROLLER:
It is useful to note that there is a helpful diagram to help you remember what the “controller” is. The main controller part to
ADF is encompassed by something called a page flow diagram which maps one-to-one with a file called faces-config.XML.
This file (or struts-config.XML when using struts as the controller instead of JSF. Oracle has switched from pushing Struts
as a controller to using JSF controller portion. This is because JSF is a widely embraced specification, governed by JCP
(Java Community Process) which always seems to draw Oracle in. Also JSF reacts at the component level, whereas struts
reacts at the page level only.) In the background when editing a page-flow diagram you are really editing faces-config.XML.
The structure of this file is not too complex. Basically this file mainly defines rules and cases within those rules. For each
web page in your system you create a rule. Within that rule you create a case for each button or link that navigates to another
page. You can also define rules that are more global in scope; for example what if you have a menu bar which you want to
be included on every page. You do not want to have to define the menu bar navigation links over and over again with each
page, so there is a syntax that allows you to define these rules and cases once and forget it. Also there is also a default rule
that will take an errant navigation back to a pre-decided location. Also there is a redirect setting for each case that determines
what the URL will say on the browser address bar and whether it will reflect the page you are currently on or not. You want
to use redirect for sure if the action taking you from one page to another could cause harm if it is executed more than once
(e.g. like charging double on someone’s credit card).
In general though you do not need to get too involved in changing the contents of the background navigation XML file if you
are using the page flow diagrammer. You intuitively define pages and use actions to connect them. Then when you create a
button you have to plug the action into the action property of that button and you are on your way in many cases.



(Please note that the faces-config.XML does many other things as well besides control navigation; it helps you keep track of
what sort of managed beans you have associated with your application. It also allows you to alter the life cycle of your
application for some advanced techniques.)

How do you navigate passing keys from one page to another?? That is a huge question that loomed in my mind when I
started learning about going from one page to another. Primarily navigation passing keys is done automatically for you by
virtue of how views object instances (collections/iterators) are linked together with view links and view instances with view
link instances. If you use the same view object instance/iterator on a couple of different pages the current row will
automatically be remembered from page to page in your application. (There are other means of customizing this
functionality. You can pass data using parameters or process/request/session beans. You can pass data from one page to
another using something called transient view objects, which are like control blocks in forms…that is, they are not really
connected to a table, like a normal view is. We will talk more about this later in the paper.)

In the page flow diagrammer you will have icons representing your application pages and lines showing what navigations
there are from one page to another. The page flow diagrammer has labels on the transitions from page to page. These are
actions which will move you from page to page for the buttons/navigation GUI objects; if a component can reference one of
these actions to cause navigation there will be an “action” property in that component’s property palette. In this editor just
double-click a JSF page icon to create/alter the page and its attributes. This will open the Visual Designer (GUI editor) in
JDeveloper.

In the Visual Designer, you can drag and drop both GUI objects from the Component Palette and the Data Control Palette
onto the Visual Designer. You can also drag operations and drop them on your page. When you drag an operation you must
specify how that operation will be manifested (if, for example, it is a button or a link). What manifestable components are
offered when you drop something depends on the operation and the component. You can drag and drop onto the Structure
window in JDeveloper which is probably easier than trying to select “invisible” elements. For example dropping an existing
button into a panel button bar would be easier if you just drop the buttons onto the component in the structure window. Also
you can sometimes click on an element and then simply click on a component and the component will go into the highlighted
element as applicable. This action is equivalent to click-and-dragging a component to the structure window or the visual
editor and dropping the dragged component where you want it.

Jspx Page definition files and “bindings”
There are lots of references to bindings of various sorts in the Oracle manuals. “Bindings” seems to be a generic term people
use when they are bored and want to sound smart. Really though: bindings are used all over the place and are very, very
important to learn about. In fact, Peter Koletzke says in Oracle JDeveloper 10g for Forms &PL/SQL Developers that
“familiarity with manually creating and editing bindings is the key to success with [ADF]”. Did you hear that? “THE key”.
So, before you learn to manually create and edit these bindings you should at least know what the kinds of bindings are that
he is referring to. In the Oracle ADF Developer’s Guide it talks about three kinds of bindings -- Iterator bindings, which
bind to an iterator that tracks the current row in a data collection; value bindings, which connect UI components to attributes
in a data collection; action bindings, which invoke custom or built-it operations on a data control or its data collections.
But Peter Koletzke says there are 8 kinds of bindings (he also says Iterator bindings should be considered separately because
they are special): Attribute Bindings, Table Bindings, Action Bindings, Method Bindings, List Bindings, Navigation list
bindings, Boolean bindings, and Tree bindings.

What is being “bound” is stuff on the model and view ends of the MVC spectrum. For example, an XML file that
JDeveloper creates and updates for you will bind an instance of a view object to another instance of a different class called a
RowSetIterator that allows a program to look at and act on the individual rows selected from the view. Thus the XML file
binds a view instance to an iterator instances. Page definition file is the file that is automatically created and kept in synch
as you create a page in the Visual Designer. This file is usually full of bindings as described above. (If you want to see the
page definition file you must open the System Navigator on the View menu and look under ViewController project
yourpackage  pageDefs  yourjspxfilePageDef.XML. Double click on it; you will see how your jspx file’s references to
bind variables originate from this file. Seeing this connection should help your understanding branch out in a good way
giving you added coding understanding and flexibility. (Hint: you can also get to this file by right-clicking (the context
menu) in the visual designer when editing one of your jspx pages)).
If you right click a field in a jspx page you will get a context menu that includes an option called “Edit Binding…”. Clicking
this will bring up the Attribute Binding Editor; here is another example of a binding: from a view level field to a view object



level attribute. You could look at this information just through the PageDef file for the page, but this presents the
information for this field nicer than the page def editor.

Here is an example of an instance where you would need to manually create a method binding: if you want to create a
custom method to associate with a button or invokeAction or some other component you will need to do the following:
• In the application module editor make sure the java node creates a java file for the application module class. Accept
this setting exiting the editor.
• In the Application Navigator, with the Application Module selected, the structure pane will show a sources folder
inside of which there should be your application module java file. Double-click on that to edit the java.
• Add your custom java method to this file. Save this file. (is a rebuild necessary at this point??)
• Go back into the application module editor and go to the client interface node. Expose this new method you created
which should now appear in the left pane of this section – i.e., move it to the right pane by highlighting it and
pressing the “>” button.
• In the page definition file for the page which has the component that you want to invoke your custom method use
the structure pane to insert a method binding into the bindings folder which calls your custom method. When the
Action Bindings editor comes up click on the app module data control and you should be able to access your newly
exposed method.
• Finally create your component or executable invokeAction and associate it with the new method binding. For
example if you wanted to create an invokeAction on this page open the page definition for the page. In the structure
pane there will be an executables section. In the executeables section will be listed all the iterators (view object
instances) which you wanted on the page. Select an iterator before or after which you would like your invoke action
to be run. Right-click that iterator. Choose to insert before or after from the context menu. Choose invoke Action
from the context submenu. In the editor that comes up for this selection specify an appropriate name in the “id”
field and then choose your custom method in the other field. Accept these settings.
(Aside: note that since you have put your custom method in the application module implementation code that means that
your code is inside the instance of the application module that your application is running against. That means you can
access (read, modify) anything the application module instances has access to (which is really all the data-related items in
your application…so your code is in a mighty good place. For example you can look up and alter any view object instance –
like setting a query bind variable -- in your application.))

A WORD OR TWO ABOUT BEANS
The Java code we just talked about in this paper is centered on manipulating areas of the model and the java code that
implements those areas. But there is also Java code associated with the view side: managed beans and a subset of those
beans called backing beans. A managed bean is a java bean that you create to do something special or to store some special
data. A backing bean is a managed bean for a particular page. In these backing beans there is one attribute for every
component on a page by default (note that there does not have to be one attribute for each component; if you do auto-binding
there will be, but if you manually create the bean you can elect to only create the needed attributes). In the managed beans
there can be any attributes at all that you decide to create. These beans have different scopes that last for the request, the
session, and the application.

Really important (according to Koletzke) that you learn to interact and manipulate the binding data through beans. Learning
to manipulate the binding data (metadata) manually and programmatically through managed beans is the key to expanding
your skills in JDev/ADF beyond that of a novice. These skills essentially allow you to go anywhere with these tools. To be
frank I have not yet learned to do this, but I would recommend studying the subject. From what I have seen you use some
managed bean code and a class called a Context to get at the entire layer of binding. It is possible to both get and set binding
data from here.

On thing I have done to date is to create a bean and get and set bean attribute values declaratively from the view layer in
various ways. One thing I learned in so doing was to use beanname.attribute, not sessionscope.beanname.attribute, even
though my bean was defined as a session bean…i.e., a bean in the session scope. Specifying the scope prior to the beanname
in the ways I was using it seemed to give me an error instead of the desired results. The error itself did not make any sense to
me, but I did manage to connect it with referring (wrongly) to the bean attribute in that apparently erroneous way.



In most cases the adaptations you might make to a backing bean will not thwart JDeveloper’s ability to automatically
maintain the code in the backing bean to match the components on the page the backing bean is for. So when you create a
new component in your .jsp(x) page JDev automatically keeps your backing bean up to date, creating new attributes and
accessor functions to match the new components. Unfortunately the automatically-added attributes have cryptic names many
times based on what type of component it is instead of being named for the function the component is playing your
application/page. So you will want to rename these attributes in a way that will change all references to it simultaneously to
avoid errors. The best way to rename and attribute in your backing bean is to click on an element in your page in the
structure pane or on the visual editor the in the property sheet change the “id” property. (Make sure the new name begins
with a lower case letter; not following this convention could cause an error later.) This change will cascade into the backing
bean automatically, renaming the attribute and accessor functions.

Here is a description of some of the experiments I did using beans of various kinds to try to pass data from one page to the
next. (I want you to know from further reading I have done that it is possible to pass data from one page to the next using a
request or session bean, but each supposedly uses a different technique than the other.) I first passed rowKeyStr (a reserved
word the value of which is a manufactured unique key to a particular row in a rowset) using a setActionListener to a bean
attribute of type String. That worked. I bound an output text to that bean (session bean). That worked, too, putting the
rowKeyStr on the new page, since I made the value of a field declaratively set to the bean attribute. Then I tried passing a
values from the iterator other than rowKeyStr; I had success in this with String type collection columns but got an type
mismatch on numerics. I guess if the source column is numeric it will not map to a java.lang.String, but defining the target
attribute in my session bean as java.lang.Number did not seem to help either: the datatype mismatch still occurred. I tried
(for the first time) to use the debugger, but it could not find the source for the setActionListener.java. I found
setActionListener.class but the debugger acted like it needed the java to really do some butt-kicking. The library for ADF
showed where the source was, but it was in a zip file and the innards of the zip were not organized as I expected so I gave up
on that and decided to start pursuing other ideas.

My second exploration involved something I heard about called process scope. This solution involved using the binding
bean for the page to set the process scope to hold the value desired. Then bind this value to the field on the target page. As it
turned out…I did not even have to use a bean. Instead I told the setActionListener to do a (from, to) of (#{row},
#{processScope.detailContacts}); note that “detailContacts” did not refer to any object in existence at the time…just a made-
up name. Then I made the target page reference #{processScope.detailContacts.Pid} as is value. This worked great! A
downside to this is that you cannot create a URL that will reference this page if you tie it to process scope. However there
are several problems (I hear) with using request scope or session scope for the same purpose. I think it is especially odd that
I could simply pull something like “detailContacts” out of my…uh…head…and have ADF be OK with me assigning to it
and referencing it later. I think in reality I am supposed to be using java to pull and push. But I had problem with some
sample code I found on the web, so I waited to use that method until my next experiment. Also it does not seem like
“processScope” is in the list of scopes you can assign to a managed bean that you might be creating. Since these attributes
and beans are created apparently automatically I guess this makes sense.

MISCELLANY

The next set of helpful topics and ideas are disparate, so the heading for this section is appropriate. Prepare for a variety of
topic, each of which seemed notable at the time I…noted them.

ADF trees: There are several kinds of tree components available to the ADF developer. The simplest is the Tree. (not
TreeTable or MenuTree). I have also experimented with an in-line table which has a tree component to it that is probably
somewhat like that of a TreeTable’s, but I am guessing somewhat here. Here is how to create a tree yourself: Drag the
collection from which the root should come from the data control pallete onto the visual editor. When you drop it specify
that you want a tree. A tree binding editor will pop up. In order to create the different tree levels you will need to create
rules. In fact you will need to create one rule per tree level. Also you will need to specify which data elements you will want
to see on each node (space separated). Finally you will need to specify which linked child collections you should specify to
connect the current rule to the next child rule you will create. This connection you would specify in the list called the Branch
Rule Accessor. It is possible by manipulating the source tags for this tree to be more particular as to how each node will
look. In order to do that you will need to do a lot of editing to the contents of the trees facet, NodeStamp. For example this
sort of editing would allow you to have one particular link level display a link that would take you to a particular page, rather
than just display an informational node. If you do not see the Branch Rule Accessors that you expect to see you need to



possibly create additional view links and view link instances on your business components diagram. Be careful that if you
specify a view link for which there is no entity association you will get a compile-time error. If JDev offers to encase your
tree in a form, do it. You will get a run-time error if you do not. If you want the tree next to your other items try dropping
the current form and the tree form into a horizontal panel component.

Turning away from trees we now look at ADF Faces switcher and JSF Facets; If you want to display different components
conditionally you can using these components together. Group the n objects in ADF faces panel groups. Drop each panel
group into a facet. Drop all facets into the switcher. In the switcher properties make the default facet one of the facets in the
switcher In the switcher, set the Facet name to a conditional EL expression using bindings. You can use the ternary (? :)
operator to evaluate an EL Boolean expression based on the number of row returned in an iterator, for example.

Now we turn to the topic of tables…the kind of table that allows for displaying of multiple rows in the user-interface of an
ADF application. As you drag a collection from the data control palette in to your Visual Designer page you will get the
option of displaying your data in a tabular format. This allows you to display multiple rows at a time. If you want to do
operations on a row in one of these tables you may need a way to select a particular row as the “current” row. Selection of a
row in an ADF Faces Core Table component is fortunately not hard: there is a checkbox in the wizard that appears when you
create the table that creates the parts of the table that allow you to select a row. Check it and you will get a radio button and a
control button which will select the current row and do the operation of your choosing on that row. If you need to add this
selection functionality later you can right-click the table component and select Edit Columns… in the context menu in the
structure window. (At one point before I realized you could click a checkbox on the ADF Faces table to make selection
possible I tried to attach the selection components manually; but I never really got it to work right. Nonetheless here is what
I did: under JSF Core there is a Selection component you can add. You can also right click the left-most column header in
the table and insert a selection column to the left. Then in the ADF Faces Core components you drag a tableSelectOne
component into the AF: table’s “selection” facet.)

Let us now look at an operation instead of a component. There is a useful built-in operation called ExecuteWithParams that
allows you to query up (i.e., execute) data from a collection passing parameter to the query. The look of this operation as you
drop it on a page can be a series of fields and a command button to execute the query (ADF Parameter Form) passing those
values to bind variables you can put in your view object SQL statement associated with that collection. The functionality of
this operation is pretty straight forward. However if you want to change the prompts to these fields you have to dig a little to
figure out how. The place to change the prompt can be found inside the variable iterator which is listed in the structure pane
under executables in your PageDef file for the page you are working on. Double-click on each parameter listed to get a
property page and change the prompt property.

As you proceed through the View layer using JSF components and operations like the ones above you will see the word
iterator and another word: collection. At times it seems these seem to refer to the same thing. “What is the difference
between an iterator and a collection?” you might be asking yourself -- as I did. An iterator is analogous to a cursor row
pointer in PL/SQL in that it navigates through a query result set. Every iterator must have an associated collection of rows
that it points to. In Java the concept of a collection can apply to any data structure that holds a series of “things” in it. So an
array is a collection, for example. Thus the iterator (or row iterator, as it is sometimes called) points in turn to each
sequential row in the collection of rows. These collections of rows map one to one with view object instances in the model
side. View Object Instances are what your views turned into after you dragged them into the application module in your
initial BC diagram. They are also the main thing inside of an application module.

A view object instance, however, is not the same as an iterator. To illustrate this note that when an iterator is refreshed it
does not necessarily mean that the underlying view object instance has been re-executed, which would re-query the database.
Also note that a data control is the view side analog to the model-side application module…which would make
collections/iterators the analog to view object instances respectively. In the page definition file, iterators are bound to a view
and a data control, which makes sense since in many ways the page definition files are the seat of many of the linkages or
“bindings” which connect the view and model layers.

So iterators point to particular rows in a row collection. Whatever these iterators point to is considered the current row.
There are various operations like setCurrentRowWithKey that allow you to programmatically set which row is the current
row. A rowKeyStr pseudo-column gives you a simple way of uniquely identifying a particular row which is passable on the
URL address line so that a particular page is bookmark-able.



Here is another interesting view-layer topic: as you create a web page JDeveloper’s new web page wizard will ask you
whether you want your page to be a .jsp page or a .jspx document. What is the difference between .jsp and .jspx? From what
If you are using any ADF Faces components there will not be any difference at all except for the file name extension;
apparently once you start using ADF: namespace components you are actually required to do straight XML; JDeveloper takes
over in this departments, as I understand it. So in such a case your file extension may say .jsp, but it will really be a .jspx.
At any rate the main difference between .jsp and .jspx files is that .jsp file can contain embedded servlet code and HTML; the
.jspx file is straight XML so instead of embedded servlet code it just uses components instead that will take the place of what
the servlet code would have coded before. There is no HTML in .jspx documents. With the embedded servlet code you can
use in .jsp files you cannot also have a good portability to non-pc-browser end-user devices…like telnet devices or palm-
pilots.

In the view layer you will see the acronym JSF a lot. It is present in the controller layer and the view layer.Java Server Faces
(JSF) is an open standard that ADF Faces is in compliance with. I have a goal to read more about this standard, but I am not
there yet. I would recommend checking it out though. One notable thing I saw about a JSF component though: JSF
components have a “binding” property that binds a bean attribute to a UI component. This is completely unrelated to the
ADF bindings we have discussed so far.
JDeveloper Pitfalls
As I have worked more and more with JDeveloper and ADF I have tried to keep a tabs on anything I saw that would throw a
monkey wrench into the learning process for newbies. Here are some of the things I observed.
• If you move your JDev home to somewhere else on your computer other than where you originally installed it, at
least the embedded server.XML and a good many other files will need to be changed. Because I had not done much
work in my JDev installation before I moved it, I initially edited all the files by hand using the os search to detect
what files still had the old directory. Really though it looked like you really needed to un-deploy anything I had
deployed to the embedded server and then let JDev redeploy it. I will have to try that next time if I need to move the
JDev home; I think you would have to use the admin.jar program to undeploy from the embedded OC4J instance. If
you simply move the directory from one place to another with out this undeployment process, you will get the
following runtime error: “06/12/07 09:13:22 Error initializing server: At least one valid code-source or import-
shared-library element is required for shared-library quot;global.librariesquot; in /C:/Documents and
Settings/scrvl.rjv/Desktop/JDevstudio10131/JDev/system/oracle.J2EE.10.1.3.39.84/embedded-
oc4j/config/server.XML.”
• When you start to try experimenting with setting up security for your application you may find there are many
options to choose from. The documentation for navigating this subject is divided into the developer’s Guide, the
OC4J manuals, and the OAS security Guide…as well as others probably…depending on what you are looking for.
One specific thing in this process I found hard was finding how and where to activate the Authorization Editor. In
order to get to this you have to open the page definition for the page in question. Then you have to click on the page
definition page, then go to the structure window and right click on the Page Def (root) node in that structure
window. There you will see an option to “Edit Authorization”. Similarly some more settings will need adjusting in
the web.XML in the view part of your application. At the web.XML file in the WEB-INF directory you just right-
click and choose properties; this brings up an editor for all the possible settings of web.XML. Also initially you will
want to alter your embedded oc4j setting which are at the bottom of your JDeveloper tools menu.
• There is a small inconsistency in the naming of the kinds of basic objects you will be working with at the business
component level. Entity Objects represent a row in a table. Entity Definitions represent the table itself. Compare
this to View Objects which represent the entire query and the view definition, whereas View Row Objects represent
rows returned from a view. It seems to me that maybe they should have been named View Definitions and Views,
or Entity Definition and Entity Rows, but maybe that is just my inexperience talking. (FWIW, the metadata of the
base objects are found in something called a StructureDef and children called AttributeDef’s.).
• If you want to create custom properties for either the application module, entities or view objects you will find that
the JDeveloper for entering these is annoying. You apparently have to select the entire string in order to add several
of these at a time. Also you cannot enter any with a null value so if you try to update the value of the first property
you enter to be the second value first then you were going to update the name…that will not work. But do not
despair: it is not impossible to create custom properties.
• Remember, when you test your applications on your embedded OC4J, that you need to include your ip address in
your proxy exceptions. At our site we get timeout errors when we don’t do this. Also the JHeadstart development



Guide warns against this kind of problem, saying you should use localhost instead. To do this you must enter the
embedded OC4J configuration tool available in JDeveloper.
• I have had to reboot a couple times because the business component diagrammer got confused and locked up the
computer doing God-knows what. One oddity is when it starts creating really long link lines when you repeatedly
delete and re-add large numbers of model level components. I almost sense that it may be better to just not use the
bc diagrammer at all for now until it is a little more stable.
• In Chapter 27.9 of Oracle® Application Development Framework Developer’s Guide For Forms/4GL Developers
(10g Release 3 (10.1.3.0) B25947-01)(hereafter called the ADF Developer’s Guide in this document) the topic is
about having view objects with multiple entity object instances within them -- each of which are updatable.
Apparently the way to achieve the feat is to check an “updatable” checkbox in the entity object panel for all of your
entity object instances that you might want to update. Instead of instructing you to do this common-sense action it
soberly and beautifully instructs you to do the exact opposite as far as I can tell (bringing credence to the old adage,
you can’t believe everything you read): When you create a view object with multiple entity usages, you can enable
a secondary entity usage to be updatable by selecting it in the Selected list of the Entity Objects panel of the View
Object Editor, selecting in turn each entity that is part of the view object definition, and deselecting the Updatable
checkbox. By the way, view objects based on multiple entity usages seems to be treated specially when it comes to
doing some DML operations. It appears to really operate on them you will need to have a very good understanding
of how Views and Entities are implemented and how to extend their functionality. Check the developers Guide for
more information in some of the advanced chapters in the ADF developers Guide.

It would seem that as things progress in the 1000-page ADF Developers Guide from Oracle that there are various typos or
omissions. I guess proof-readers can only do so much because they are not necessarily subject matter experts of what they
are reading…kind of like when your spell checkers auto-corrects your word to be spelled right but it’s the wrong word for the
context. Most of the errors I have run into are pretty obvious when they occur if you have been reading sequentially through
this Guide. But in addition to the one above I would like to alert you to a few others:
• In section 9.7 right before the first example in that section there is a reference to ServiceHistoryImpl entity row
class. This should be ServiceRequestImpl. This typo is somewhat confusing.
• In example 9-16 there is a reference to a method called getUserIdForLoggedInUser that they use but they do not
explain. I think this would just be a custom method in the SRServiceImpl application module class that would get
the current row from the view in question and then get and return the userid attribute from the view. Perhaps I am
spoiled but really they had up to this point been so good about explaining where each bit of code comes from.
• In section 9.6.1 I got very confused (Creating View Objects at Run Time for Validation). It would have helped me
to understand better if they had mentioned that the view object instances that are used for validation would need to
be named with a certain naming convention…not the views themselves. The convention for a view with the fully-
qualified name of a.b.c.theView is that the view object instance for that view if it is to be used as one of these
validation views should be named Validation_a_b_c_theView.

Here are some other JDeveloper potential pitfalls:
• I think if your JDev instance is forcibly rebooted while it is open and certain changes unsaved, the reboot can
corrupt your installation. I ran into a problem and reinstalled JDev and the problem went away. (Here were the
problems: if your ADF Faces Core component palette icons turn to all angle brackets (< followed by >) I found a
work around to bring JDev back to its senses. (I do not care so much about the icons but rather when you drag these
angle brackets into the visual editor the visual display looks completely different…it’s like the visual editor does not
know what to do so it reverts so some tag mode…which is not very helpful.) So the work around is to go to the
view controller project properties page. Click on jsp tag libraries. Uncheck the box to display the properties in the
component palette for the ADF tag libraries. Click OK. Confirm that ADF Core option has disappeared from the
component palette. Go back into the project properties and recheck that box. Now the icons will be restored but the
drag and drop still brings up the primitive functionality.)
• In the property sheet if you change a property and then press Save All button it will reverse the property you just
changed, so get out of the property before saving.



• In an oracle document they indicated the Rendered attribute of a ADF Faces component called a PanelHorizontal
could receive a data-driven EL expression as a property. In reality it appears you need to edit the jspx file to do this,
whereas in the document it indicated you could click on the attribute and there would be an ellipsis (…) allowing
you to enter the EL expression. If you set rendered to true or false (these are the only values JDeveloper visual
designer editor property sheet would allow you to set rendered to – through a dropdown list) the Source tab of that
jspx file will show rendered=”true/false”. If you then enter a boolean EL statement it will conditionally render this
component. Oddly enough the property sheet dropdown list will go away and will be replaced by an ellipsis field as
described in the documentation. Maybe this is a difference in sub-versions of the JDeveloper product and the
documentation; or maybe it is just the author forgetting something. (You can use the Bind To Data button when you
are selecting a property that could potentially have EL in it. The icon for this button looks like a database icon
(cylinder…like a disk-pack))
• If you use bindings EL expression to keep a record counter against an iterator, and the iterator’s RangeStart
expression does not seem to be advancing make sure that the page definition file’s setting of Range size is set to the
number of rows displayed on the screen is set to the right number. The default for this attribute for iterators seems
to be 10.

At various times in my journey of learning ADF I hit various plateaus of learning. One happened when the idea crossed my
mind, “How does one go from one page to another and carry the context with you?” This literally threw me off for weeks. I
do not know why learning about this topic had to be so hard…I begin to feel like I had been trying to figure this one out
forever. As I mentioned before in this paper the table select one component will fairly easily go from one page to another if
the in the data control palate you use the same iterator on the source and target pages. In learning about other aspects of
passing data from one page and regaining the same context on another I experimented quite a bit; here are some the
experiments I underwent:
• It would also appear you can create links when you use the setCurrentRowWithKey operation as well as the
rowKeyStr pseudo-column. You can drag the operation from the appropriate iterator from the DataControl palate
near a column in the table of data. Then it is possible to alter the page definition file of this to alter the value of the
parameter of the action binding that was automatically created by this operation-drag. Although this maneuver was
described someone in a manual I was reading I was never able to get this to work.
• I also tried creating my own managed session bean in the prescribed manner; I initially when I did this I got an error
that made it seem as if the bean was never initialized and the constructor method was never called; this was due to
the way I was referring to the bean attributes (through the sessionscope) which was not what ADF was expecting.
• If you have an ADF Faces table with a current row selection aspect, it would appear from some on-line JDeveloper
documentation that you can create an ADF Faces action listener as a child to the command button that comes with
this table. The sole purpose of this action listener is to wait for someone to press a button, and then do a copy from
some value to some other place right before the action associated with that button is carried out. The action listener
component, for example, might have the following as the from and the to values, respectively: from of
#{row.rowKeyStr} and to of #{requestScope.rowKeyStr}.

At another point in my learning I was trying to delete and create in turn both the model and the ViewController projects.
During one of these experiments I got oracle.jbo.ConfigException: JBO-33001: Cannot find the configuration file
/edu/usafa/camis/sandbox/test2/model/common/bc4j.xcfg . I looked for quite a while trying to solve this problem before
dropping back and going with what I knew at the time. In metalink there is a doc id of Note:267048.1 that related to
JBO-33001. This note speaks of JDev producing code that uses libraries that are out of alignment with the oc4j libraries.
That problem description did not fit with the basic thing I had tried to do, though. I would recommend at least initially
that you create and ADF bc, JSF application and then use the entity from table wizard to have the wizard do as much of
this work for you as you can up front, without having to create the individual pieces. At this point I know that a
ViewController and a Model project are bound together most easily by looking at the dependencies node in the
ViewController project properties. There is a checkbox that needs selecting. But if you do not know that checkbox
exists you can spend a long time looking. This may help you if you have to drop and recreate the ViewController
project.

Here is a good hint: if you run into an error it may be helpful increase the granularity of the logging that occurs while your
application is running. Although the online JDev documentation is slightly wrong (they do not tell you the right directory



look in to see the file you have to change to alter the logging level) you can go to
<JDevhomedir>jdkjreliblogging.properties In this file you need to set java.util.logging.ConsoleHandler.level=FINE
and then add the line to this file: com.sun.faces.level=FINE
Then you get messages like the following…
FINE: getValue Result:000200000004C3030F4200000003C20863000000120000010E1BF42914
Oct 5, 2006 10:50:02 PM com.sun.faces.el.ValueBindingImpl setValue
FINE: setValue Evaluation threw exception:

JHeadstart extension to JDeveloper
JHeadstart like its predecessor Headstart is something you generally have to pay extra for. But it is a good productivity
enhancer most likely depending on your needs. With our site license it is part of our Supplemental Option.
JHeadstart extends JDeveloper. Much of its functionality lies in the ViewController section. All the things you learned
about setting up the model part of your application are apparently still necessary for this productivity enhancement tool. This
tool allows you to more quickly generate the View/Controller layers of your application.
The two versions I worked with for this product were easy to install. 10.1.2 was available for free download at the time I
investigated. The installation process for this version was manual. The Zip file came with install.html that walks you
through the process. It was about 5 steps: unzipping, copying some jars, copying an XML file, open JDev and tell it where
jhst home is. But now the update manager pretty much does the whole thing for you. I was fortunate to be able to download
the latest version because the company I worked for had paid for the Supplemental Option of our site license which entitled
us to download this software.
Although I know it is an option of the JHeadstart tool to be able to access and work with module definitions in an Oracle
Designer repository I did not experiment with this technology. My focus has been more on learning how to manually work
with and understand ADF on the manual level. Other members of our team were tasked with better understanding this
technology however.
There is apparently quite a bit in the JHeadstart view layer generation that is configurable – just like in Oracle Designer
module generation. In some cases JHeadstart creators have tried to parallel the creation development environment of
Designer and Headstart in this. One thing is different however; the designers of JHeadstart are no long pushing 100%
generation very hard…at least at this point. They are instead touting this tool as a generate until you have done all that is
reasonable, then cut over and do manual changes the rest of the way.
This tool helps to keep a consistent look and feel just like regular Headstart: Oracle uses a skin type for its portal
applications which it calls BLAF (Browser Look and Feel). Also ADF Faces/UIX use BLAF by default. This BLAF was
tested in many usability tests by Oracle and is the results of these tests (as well as internal and external comments on it, no
doubt).
I have heard that there are competitors to JHeadstart but I have not put energy into finding out more information about them.

Taking it for a spin.
At the time of writing this paper JHeadstart 10.1.2 was available for download by anybody at
http://www.oracle.com/technology/consulting/9iServices/JHeadstart.html . That version is compatible with JDev 10.1.2.
While this version is informative to play with 10.1.2 to 10.1.3 represented a huge change. It is almost pointless to try and do
any real work with these older versions at this point because of the direction it would take you.

Whatever version you use I recommend creating a trial application. To do it you really only need a few tables which have
parent/child relationships. Create a model for them (entities, views, application module):
• Create a db connection on the Connections Navigator. (If you are familiar with tnsping or tnsnames.ora, creating
such a db connection should present no issues.)
• Once you have the db connection created drag some tables from the db connection to a business components
diagram, create some views, drag the entities into the views, connect views with links as appropriate (following fk’s
of tables), create an application module, drag the views into the application module, and connect them with view
link instances (again follow fk’s of tables). (Note: to edit which db connection your application will use right-click
the application module and choose the Configuration Editor. From there you can edit these settings.)



• For the ViewController project, right-click the project and click “Enable Headstart for this application” from the
context menu.
• After JHeadstart-enabling the ViewController project, you can right-mouse-click the project and choose quot;JHeadstart
Application Structure Wizardquot;. In this wizard, you can select any ADF Business Components application module
from all model projects included in your workspace to base your web application on. (Note: in 10.1.3 this was
renamed to the command “New JHeadstart application definition” in the viewcontroller context menu)
• To generate a struts-config (note: in 10.1.3 changed to faces-config) and pages using JHeadstart, right-click the
Application Structure File (note: 10.1.3 now called application definition file) and choose quot;Run JHeadstart
Application Generatorquot;.
• Run the generated application by starting index.html (or by running the ViewController project).
• Like most Headstart products the default creation is basic and functional but it is a lot of functionality in a very short
period of time. Also changes to the basic generated application vary in difficulty depending on what changes you
want to make.
• JHeadstart issues/pitfalls
• If you are trying to use the 10.1.3.0.4 version of JDeveloper against a version that is earlier than 10.1.3.0.97 I have
seen a coworker get errors due to that. When you try to run a generated application it may give errors related to
“whitespace” being needed.
• Note: before running a generated application it is a good habit to always rebuild the viewcontroller project before
running. I think the reason for this is that JHeadstart makes a bunch of changes after it is done generating that
require rebuilding. It tells you to rebuild in the log, but who reads warnings on the JHeadstart error log…? 
At one trial of this product I got the error: code segment of method _jspService(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse) too large -- if you remove some attributes from a view with a lot of attributes this
clears up. This occurs when you try to run the viewcontroller project sometimes. In my case it seemed to occur when I made
a view out of a table/entity that had a huge number of columns. (like 100 or so…)

SOA – Service Oriented Architecture
The desire of management for going to this type of architecture was to enable us to do implementation of our services with
whatever technology is currently available. Today it is Java. Tomorrow it might be…who knows.
This means that established data interfaces between two organizations in our company, or two parts of the same organization
or system will need to be defined in a way that will balance usability with maintainability.
Ask Paul how he feels the proposed technology configuration will support SOA. I think he visualizes anything being put into
portlets. So the interface he may be talking about is that we write a program, and it interfaces with OAS’s Portal framework
so that it is displayed and is run-able by the clients of our system.
I would like to study SOA some more, but this paper is due to the RMOUG office soon for printing.

A Few Random Parting Tips
Like the Titanic I feel I have just bumped the tip of something very big. My next goal is to make JDeveloper “mine” as it
were by continuing to play with it and use it in pilots and eventually production-level work.
Here are a few parting ideas that I have encountered for you.
• At some point in creating your application JDeveloper asks you what sort of DOCTYPE to use. Don’t use xhtml 1.0
strict; doing so causes an error at runtime with my current build of 10.1.3.
• If you need to debug your model code there is already a “main” method built into your application module
implementation java file. If you run the application module you can do so in debug mode by using the right-click
context menu. JDeveloper will allow you to use the business components browser to test your business tier. This
browser is kind of cool anyway. Running it in debug mode is even cooler.
• As you publish your custom methods into your client interfaces you may not be able to immediately reference your
new modules in java code editor’s insight function (where you are prompted to complete your code automatically)
by using the structure pane to request that your client interface be rebuilt for your object.



• There is a neat and simple program (which eventually turns into SRDemo) that the ADF Developers Guide for
Forms developers that starts in chapter 5.7 and continues building on that simple program. I found the program
extremely useful for demonstrating the reality behind the GUI JDev IDE. Among other things it shows that there
really is a class called an ApplicationModule and that that class “contains” View Object Instances, which are
findable, queriable and displayable. I recommend copying it and running it for your own sanity. In the same way
you down load extensions from technet using JDeveloper, you can download this program and analyze its code to
verify and reinforce what you learn.
• In application modules when you learn how to create you own custom methods note that nothing much can be done
in the constructor with the application module itself. It would appear that the default constructor which is created
for you (if you choose to tell your application module to generate a java file) does not represent the true beginning of
the application modules life. If you want to reference the application module right after it has been created and set
up you must create a “create” method which will override the create method of the super class. So in this method
you call super.create(), then you do whatever you want to do with the app module which needs to be done at the
beginning of the application module’s true life.
• Later when you are a bit more comfortable with writing procedures within the extensions that JDeveloper can
automatically create for you for each entity and view object, I would recommend reading (or trying to get through)
Chapter 25 of the ADF Developer’s Guide for forms/4GL Developers. It has so many important concepts in that
one chapter. For example this chapter alone covers how/why/when to extend base classes, how to call stored
procedures and functions, and how to create your own Framework Extension Layer library which will save you lots
of headaches down the road. (Really somehow this last topic should be incorporated somehow WAY before chapter
25 I think.)

Interviews
During the creation of this paper I interviewed many people where I worked. I think these interviews added to my
perspective. I would like to thank each of the people I interviewed for sharing their time and their thoughts. I hope I have
been able to capture some part of their thoughts in the sentiments of this paper.

Resources
As you find your favorite learning resources they will lead you to other resources.


Metamorphosis from Forms to Java: a tech lead's perspective (paper)

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to Metamorphosis from Forms to Java: a tech lead's perspective (paper)

Similar to Metamorphosis from Forms to Java: a tech lead's perspective (paper) (20)

More from Michael Fons

More from Michael Fons (8)

Recently uploaded

Recently uploaded (20)

Metamorphosis from Forms to Java: a tech lead's perspective (paper)