 |
Wednesday, March 24, 2004 |
After much procrastinating, this morning I bit the bullet and imported the full ADF Toy Store demo into CVS from inside JDeveloper 10g, build 9.0.5.1.1583 (our latest release candidate from yesterday). We're down to the last few showstopper bugs, so I figured I'd better try it before finding out there might be some issue with checking it all into source control.
Following on from the advice Dave gave me last week about setting the CVS-level option to treat *.jar files as binary, I repeated those steps for *.gif and *.jpg files that the demo uses.
The import module went smoothly.
I visited all of my code files to add in the $Header$ tag in the appropriate way for *.sql, *.java, *.xsl, *.xml, and *.jsp files. I appreciated that for compound components like BC4J entity objects, the visual icon-overlays appears *ALSO* for the "Sources" folder in the structure pane for those compound components. Nice touch!
I used the new "View Uncommitted Files" window which showed me 146 files pending commit, and with one button committed them all with a common CVS comment for all the files I touched.
I noticed that a nice "History" tab now appears on all my source code files, and I've played around with using it to see and compare previous revisions of my files.
A big thumbs up to our guys in the UK that work on our CVS source control integration features. Everything went without a hitch!
3:44:58 PM 
|
|
After answering this question for an internal Oracle employee on an internal JDeveloper mailing list, I figured it was time to write a short little article on it. The article explains what causes this exception and how to troubleshoot your application if you are getting this error when it's not really the case that another user has modified the row underneath your feet.
3:25:21 PM
|
|
JDeveloper can launch a PL/SQL stored procedure in interactive debug
mode and you get rich, debugger support just like for Java. This
feature works with 8.1.7, 9.2, and 10g of the database using JDeveloper
9.0.3 or later. This works well if you are able to supply the right
parameters to the procedure invocation in order to reproduce the
problem. However, sometime your PL/SQL is executed in response to some
other database activity, and might require the environment provided by
the invoking code to work correctly. Some examples might include:
- A database trigger that fires based on the insert of particular data
- A procedure that is invoked via the Mod_OWA Apache model for building PL/SQL based web applications
- A procedure that is invoked by Oracle Workflow
- A procedure invoked by a .NET client (or other type of client that might invoke the stored procedure)
A In
those cases, it's possible to reverse the roles and rather than having
the JDeveloper debugger start your procedure, you can have your
procedure contact the JDeveloper debugger in reverse.
The only required steps to get this reverse "callback" debugging working are:
- Decide on a port number to use for debugging. The default is port 4000.
- Visit the "Debugger / Remote" panel of your project properties
and enable remote debugging with the "Listen for JPDA" option selected
- Click the "bug" icon to start your JDeveloper debugger in
listening mode, and leave the default of 4000 for the port number. You
can indicate which JDeveloper database connection definition should be
used for finding PL/SQL source code as well.
You can tell that
you have a debugger listening for remote/reverse connection by looking
at the "Run Manager" in JDeveloper. You'll see a node like "Debug
Listen..." in the tree. - Add the following line to the place in your PL/SQL code where you'd like the debugger to be connected:
dbms_debug_jdwp.connect_tcp( host => 'localhost', port => 4000);
- Cause your stored procedure to be executed by some appropriate
means (requesting the page in the browser, doing something appropriate
in Oracle workflow, Running a Forms application that invokes the stored
procedure, etc.)
That's it.
A few tips on PL/SQL debugging in general:
- Make sure your source code is compiled in debug mode or you cannot stop at breakpoints in the program unit. You can do ALTER PROCEDURE procname COMPILE DEBUG
to recompile with debug (or re-save the procedure from inside
JDeveloper's PL/SQL source code editor after browsing it in the
connection navigator. That will compile with debug by default)
- You might consider conditionalizing the invocation of your
debugger connection for procedures requiring this
"reverse-connect-to-JDev-debugger" approach based on the presence of a
row in some utility table, or on the value of a convenient package
global variable which could be easily set to true or false when you
want to debug.
1:43:24 PM
|
|
If you've just installed CVS for souce control and performed your:
$ cvs init
to
initialize your CVS repository, then you will still be missing one step
in order to succesfully use CVS with most java applications that make
use of componets from JAR files. I got bitten by this recently, and
Dave on our team was kind enough to diagnose the problem for me. After
going to the "Connection Navigator" and creating a new CVS
repository connection under the "CVS Server" folder (in my case, a
local repository on my own laptop), I was trying to checkin an entire
Application Workspace, with it's Model and ViewController projects.
Checking the lot into CVS was easy enough. A single right-mouse menu
pick on the workspace "Import Module..." and clicking (Next>) a few
times, taking defaults, through the import module wizard. This checked
all my files into CVS and checked them back out so I could keep working
on them.
Aye, here's the rub. By default CVS doesn't come
configured to treat JAR files as binary, so during the module import,
some of the JAR files (like standard.jar which supports the
JSTL tag libraries, for example) were getting checked-in and
treated as text files. So, upon checking them out their contents was no
longer full of the precious class files that were needed to make my
JSTL tag libraries work correctly. The symptom was that after importing
the module, a rebuild of my project was giving JSP page compilation
errors like:
Error(1) java.io.EOFException Error(1) Unable to load taghandler class http://java.sun.com/jstl/core Error(2) java.io.EOFException Error(2) Unable to load taghandler class /WEB-INF/struts-html.tld
Dave set me straight with the advice to: - Checkout the cvswrappers file from the CVSROOT module
- Add the following two lines to it:
*.jar -k 'b'
*.jar -m COPY
- Commit the file
Which I did, and now everything works as expected.
10:46:22 AM
|
|
In the last few weeks I've switched my default browser from Internet Explorer 6 to Mozilla FireFox 0.8.
I've been using FireFox as
my default browser (including running all my JDeveloper web
applications demos with it during seminars and dailying
testing/working) and it's passed the trial by fire. It's faster than IE
and despite a few small bugs with tooltips that will hopefully be fixed
in later betas, it's a solid browser that does what it's supposed to.
I used a tip from Jon Udell's blog
to develop some custom search plug-ins, and just how easy and elegant
this was to do alone (and how much it has already proven useful to me!)
would have convinced me alone to switch, but I keep finding little
things I like about it.
Recommended!
10:07:12 AM
|
|
During the partner seminars on ADF that I did last week, I
demonstrated a little-known feature of the ADF Business Components
framework which we designed to respond to a frequent requirement of
Oracle Applications: on-site customization.
I built a quick demo of some business components to manage
instances of Employee business objects, mapped to the underlying
well-known EMP table. On top of that, I built a quick rich client Swing
interface with a generated panel. We used this little application as an
example of the "Version 1.0" application that shipped from the
vendor/software-house to the customer site.
Then we proceeded to build a project that applied on-site
customizations to the business objects delivered with "Version 1.0" of
the application:
- We created a new project in which to work on our customizations
- We created a new library definition in our project, using the JAR file full of "Version 1.0" business components as the JAR
- We used the "Import..." menu to import "Business Components" and
we used the file dialog to pick the package XML file corresponding to
the package containing the "Version 1.0" business components we wanted
to customize.
We noticed that imported ADF business components were not editable in
the customizing project -- which is by design -- so we simply created a
new component (in the demo we built an com.ourcompany.ExtendedEmp entity object component that extended the imported com.appvendor.Emp
component. Using the Entity Object wizard we added an extra attribute
to the customized employee object, and we added some custom validation
rules (two common things that occur during on-site customization of
applications).
Then here was the kicker. We edited the "Business Components"
project-level options of our new project and declaratively indicated
that we wanted to substitute all runtime use of com.appvendor.Emp by our customized version of it named com.ourcompany.ExtendedEmp.
Then we re-ran the self-same user-interface shipped with "Version 1.0"
from the original application vendor, and now our new business rules
were being enforced without touching the original application.
The part of the demo that I didn't have time to show (which would have
further underscored our interesting application customization features)
would have been to walk through the scenario of having the "customer"
upgrade the application to a "Version 1.1" from the original vendor
(with perhaps bug fixes and some enhancements to the base components),
and show how just by restarting the application the on-site
customizations done in those extended components keep working without
hand-applying any customizations to the original vendor's source code.
I think this simple demo went across well in both the Rome and Milan
audiences, since all of the Oracle partners realized what a royal pain
it is to support on-site customizations today with their existing
technology stacks. As it is with so many parts of the Oracle ADF
framework, even in this area we've already done the hard part for you.
:-)
9:36:13 AM
|
|
© Copyright 2008 Steve Muench.
|
|
