JDeveloper

Questions

Answers

Dave Wendelken asked:

I created a workspace and project, then I realized that I wanted the names to be different.  So, I used the file-rename menu option for the files.  However, the default directory names did not change to match, they kept the old file names.  How can I get it to switch the directory names also?  I saved and closed the files in the workspace, then changed the directory names in the operating system, then reopened the project.  The files were there, but they were now empty! 

This really touches on a basic problem in the Java environment.  You are not working in a repository;  you are working in a code generator. The ability to rename objects after creation is virtually an intractable problem.  We have found, in every release of JDeveloper that renaming is not very safe.  You have to know exactly what the generators are doing when you try to rename something.  You cannot count on the renaming to do what you might expect.  The problem stems from that JDeveloper does not know whether you overrode the defaults on generation.  So when you rename one component, it can't safely rename other generated components. 

There are so many combinations of this kind of thing that there is no way that the testing scripts would have caught much of the weird things it does.  All we can do here is report what we did and what you expected the refactoring to have done and then to suggest how they can improve the algorithms.  At the end of the day, renaming will never be safe. 

Even deletion and recreation is not always safe.  For example, dragging and dropping an element onto a JSP page makes both the component and the binding.  Deletion of the component does not delete the binding, so if you recreate it, you will get two bindings to the same data column.

Paul Dorsey asked:

We are trying to build a struts JSP using ADF business components.  We are trying to programmatically control the BC layer. 

Task 1: How do I call a database PL/SQL procedure? In 9i with BC4J I would use a BC4JContext in the struts action class to get access to the BC4J stuff.  But that all seems to be replaced (or at least renamed) in 10g.  Are there any examples that show this being done?

Steve Muench replied:

The ADF Binding Primer white paper (http://otn.oracle.com/products/jdev/htdocs/adfprimer/index.html) goes through an example of the new way that the ADF/Struts support works and how to get hold of your application module now.

Calling the stored procedure from inside an Application Module implementation class (or an entity implementation class) is the same as before.

Only the mechanism for getting hold of your data control is new. As the example explains in the white paper, you can find your data control from the binding context, or use the ADF Data Action to handle a lot of the details for you.

------------------------------

The question really is: how do you get a reference to the current app module (from the HttpServletRequest !§request!?) in the struts action class?

I'd recommend taking advantage of the ADF Data Action which does it for you, but the article first goes through a bare-bones example without the Data Action, then shows an example using the DataAction, then takes that one step further to illustrate how to accomplish the method invocation in the previous step in a declarative way.

Paul Dorsey asked: How do we execute a generic SQL statement?

(Begin myPackage.myProcedure(xxx) End;). 

In 9i, I would have used the taglib: /webapp/DataTags.tld.  But in 10g that is replaced.

Steve Muench replied:

Generally any data access should be done in your business layer. I'd put this code inside a custom application module impl method, then invoke that method from your controller layer in the struts action.

Paul Dorsey asked: How do I programmatically assign a value to an attribute?  

In 9i, I would use a setAttribute in the same DataTags.tld taglib.

What is the new name for /webapp/DataTags.tld?  Is there documentation or examples on how to use it?  This is the lib that is aliased as !§jbo!?.

Steve Muench replied:

You can find your binding object in the binding container, then call the method on the binding to set the value. This automates handling all of the other layers.

Again, using the DataAction, this common part of a web application lifecycle is handled for you automatically.

CLOB Headache

Garry Devinger asked:

I'm another oracle developer new to Java (three weeks).

1.  How can I view CLOB data using JDeveloper connection?  I can see the table structure and other data in the table, but not the CLOB data.

2.  How can I view, bring back CLOB data from a table, into a webpage?

3.  For consensus, is it best to put CLOB data in a table or an outer file?

Dennis Menor supplied the answer

Try "'Illustrating Use of Large Objects"sample code, see URL below: http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/advanced/LOBSample/Readme.html

7

Michael Mullin asked:

I'm currently involved in a development project for a strictly web-based product with an eye on future portal deployment.  The potential customer load could be in the thousands.  I have worked with Developer 1.5 thru 6.0 in the past and I am quite familiar with Forms and Reports developer tools, but have not played with JDeveloper.  I and am looking for some feedback to a few questions:

1.  What are the pros and cons of both 9iDS Forms Developer and JDeveloper? For instance, Forms Developer is a robust tool that can generate some pretty sophisticated forms rapidly (pro), but to deploy those forms I incur the costs of 9iAS licensing (con).

2.  If you had "deep pockets" and were versed in both JDeveloper and Forms Developer, which way would you lean?

3.  Does anyone out there know if the Department of Defense has any current restrictions on java applets?  Back in '97 I was working a project and was told by an Oracle rep that java applets were forbidden on DoD systems.  I've been able to track down a DISA memorandum that lumps java applets, JSP, ASP and Active X into a "mobile code" category and insinuates DoD has security concerns with these, but I can't find anything that specifically says you can't use them.  In deed, the Army portal is almost entirely JSP.

I don't want to open up a big "us vs. them" debate on this.  Just looking for some honest opinions.

JDeveloper is not one product.  You can build all sorts of stuff with it: Java applications that can deploy Client/Server or as applets,  JavaServer Pages, EJBs, Web Services

Soon we will have JSP/UIX wizards to build JSPs that do not require full screen refreshes. So, first you have to specify what you are talking about.

JDeveloper competes with full featured Java products so it is a little weird for us to evaluate. It is not an exact correlate to Forms.

Here are a few alternatives:

1. Forms on the web

·         Most efficient development

·         somewhat of a nuisance to deploy and maintain clients JInit  (do we still need that?)

·         Requires 9iAS

·         Applet based so some security concerns (but it IS secure)

2. Java Clients as Client/Server

·         Most flexible environment, you can build anything you imagine

·         Not a quick development

·         All the "joys" of Client/Server deployment but Java WebStart can help

3. JavaServer Pages

·         UI that has all the charm of a web page

·         Not easy to work with

·         Lots of things learn (Java, HTML, JavaScript, etc.

·         Can be deployed on any application server, such as Apache

·         Only suitable alternative for external users

4. JavaClients as applets

·         Most flexible environment, you can build anything you imagine

·         Not a quick development

·         Nice deployment

·         Some security concerns

Bob Syslo-Seel wrote:

Dear Oracle True Believers,

I need your help to argue effectively AGAINST implementing a thin client VB .NET front end against an Oracle database. You may find it incredibly odd that we are arguing about this kind of stuff here, but I need more than your sympathy.  I need hard evidence of problems or complications that illustrate that this is a stupid idea.  (If it ISN'T a stupid idea, I need to hear from people that have done it and lived, because I'm not sure I believe it’s possible.)

I am particularly concerned that--especially if improperly implemented--we will not have an app that can do the following:

1.       Row level locking--can't assure transaction and data integrity without it. (silly that I have to insist on this, but there you have it.)

2.       Ability to have a real-time connection (or at least preserve the state of the data for the duration of the transaction) or roll back if the transaction fails.  A recent VB app they built here could only use REF CURSORS to extract the data into the app. and hope it didn't change before the edits were sent back.

3.       Ability to call stored procedures in the Oracle database and that means pass parameters in and receive parameters back.

4.       Ability to receive Oracle database error codes and display user-defined messages in the app.

5.       Ability to sign into the database with an individualized username/password that can be monitored by the DBA at the session level.

Around here they like to validate usernames and passwords "in the application" (Ha!) which means that your single - sign-in and strong password features are bypassed. Any other gotchas?  Any complications we can expect? Help me please. I need better weapons to fight against the "dark side"! I might be willing to live with this if it can at least be made "as good as" Oracle's toolset.  It would be particularly painful if it happens anyway and they ignore known problems.  Maybe later I can argue the obvious point: "It is easier and faster when using the Oracle tools.

John Caputo replied: 

If you have a browser based application (Web Forms, PSP, JSP, PHP, Cold Fusion, whatever), no matter what front end you have,you can't do many of the things you want unless you set things up a certain way. Persistence isn't possible (real time connection), but you can do things to preserve state, but a rollback won't work in that case. There's a way to simulate real time with 9iAS/10gAs. The app server will hold the connection open until you tell it to close it or timeout.

The problem you need to address here is what the client is trying to accomplish and offer a browser-based solution that meets those requirements. Also, you don't design web applications like Forms. Why do you need to rollback more than one page's updates? Make the page large enough to hold all data to be updated and do the update in one return to the server. You then don't need row-level locking across pages.

All web apps I've developed have the problem of data changing between sending a page and receiving the user's updates. Need to build in a check. Executing stored procedures isn't a problem - they execute something now that returns a ref cursor. You can execute functions that return a value as well. Don't laugh at application authentication. It's done all over the place. Sometimes it's necessary.

 I think it's a matter of how you approach the requirements. Browser-based apps need a different perspective. It isn't client server.

Can .NET do the things you want? I haven't worked on a .NET project but I have seen apps developed at sites I've been at. I believe error handling isn't a problem. There's a way to do it. Sign-on to the DB is simple and fast in Oracle. It used to be slow if you had a different front end and connected. But Oracle has just released info about integration with Microsoft products and maybe the connections are much faster now.

 There are obvious, but not overwhelming, advantages to using Oracle products for development, so it may be a hard sell, especially if your client has many .NET experienced developers.

Does this help? Sorry I don't have personal experience with .NET for comparison. But I've seen some pretty slick apps with .NET front-end and Oracle back-end. Hard to say without knowing more if Oracle is a "superior" front-end.

-------------------------------------------------------------------

Paul Dorsey replied:

It is not a matter that it can't be done.  It is more a matter that it probably won't be done well.

To be honest, you have EXACTLY the same problem in J2EE unless you use ADF BC.  Nothing is automatic.

The argument is really not against .NET per se.  It is more about having to do everything by hand. Imagine trying to write a C program without Pro*C (using only raw OCI calls) and you will get an idea of what you are up against. .NET applications have been written and written well (or so rumor has it), so you can't make the argument that it can't be done.

There is an argument against .NET that holds some water. .NET is not a particularly enterprise-rich development environment as compared to J2EE (particularly with ADF BC). The really cool thing about J2EE is that it separates out the View and Controller logic.  In older thinking (including Forms) how screen navigation was done and what happened on the way was hard-coded into each of the screens. In Forms, we navigated between screens using a new form or CALL FORM command.

In J2EE, we separate out that logic into what is called the Controller layer. This allows you to nicely partition the logic into "between-screen" and "within-screen".  The between-screen stuff is done using a state transition engine metaphor (Struts is the standard here) where each screen is a node.

 J2EE seems to have won the mind share of serious developers so you can count on more widgets, interaction, cool stuff etc. coming from J2EE than from .NET. 

On the other side, it is easier to get up to speed in .NET.  The J2EE stack is much harder to learn.  All of the sophistication comes with the price of greater complexity.  You will be productive much faster building in .NET but you may only be fooling yourself.  Like the saying goes "everything works with scott/tiger".  You may think everything is wonderful until you get to the point of scalability tests, and then your project never succeeds.

In both architectures, it is essential to run full-scale stress tests with whatever architecture you have chosen prior to doing heads-down development.

Ryan Gaffuri asked:

In our shop, the Java developers do not want to use any database stored procedures and only put logic in the middle tier.  Is this a good idea?

Paul Dorsey replied.

No, this is not a good idea.

If you use stored procedures, you will need someone who knows the database as well as the front-end tool used in your development shop.  If you are a one-person development shop, I think you can make your argument stick.  If the number of developers is greater than one, there is no reason to not use the strengths of the database to your advantage.

 Consider the following advantages:

1)       Performance: Routines that are database-intensive are much easier to write in the database. Java, .Net, and other non-Oracle developers are usually not very good at database-centric development.  We recently rewrote a 6000-line routine that ran in about 20 minutes in Java to < 5 seconds in a 500-line PL/SQL routine.  Bulk operations, etc, are much easier to invoke from PL/SQL.  If you have a complex routine that requires hundreds of database operations, sending those operations over the network will hurt performance. We rescued one routine where there was more data being sent to the database (large SQL queries) than was being returned (data). 

2)       Object-Oriented (OO) encapsulation: Moving logic down to the database makes that logic available to any front-end routine. You can use it in your application and in your report writing tool, and then if you want to generate a flat file from the database you can use it for that too. Or if you want to make it all into a materialized view, it is already in the right place. Placing logic associated with the persistent objects is more logically placed near those objects.

3)       Which architecture is more likely to change? The front-end or the back-end?  Most Oracle shops will probably still be Oracle shops next year. User Interface (UI) architecture is in flux.  Should we use Java, .Net or HTML database?  If you are a Java/J2EE shop, the industry standard last year was JavaServer Pages (JSPs), this year it is JSP/Struts; next year it will probably be JavaServer Faces (JSF).  Should you use ADF BC, Hybernate, or EJB3? All that you can be sure of is that the way we build the UI this year will probably NOT be the way we build it next year. If you place your logic in the database, the amount of code you will need to refactor is minimized.

4)       Configuration management.  Code that resides only in the database is easer to modify than application server code.  Application server code updates always require bringing down the whole system.  Many database changes can be done on the fly if necessary.

5)       Partitioning of the application:  I find dividing the application helpful.  We actually push almost everything to the database using what "ultra-thin" client development.  All the UI does is presentation of the screens.  We even move most of the UI rules down to the database. When a user right-clicks an object, the options are driven by a database procedure. Whenever we want to change the rules for what options are available in a particular context, we don’t have to look through six levels of nested OO Java classes because the options are in an easy-to-find and maintain place.

The most solid evidence I have for this opinion is the thousands of lines of poorly performing Java code that I have been able to replace with PL/SQL code that is a fraction of the size and runs many times faster.

I have to agree with you that most shops do not work this way.  I have had this argument numerous times with Java and .Net types.  The most common argument against a thick database approach is the one you cite, namely that you don't have anyone in your shop who is any good at it. So hire someone.  We all recognize that writing a good J2EE application requires having a good J2EE person around.  Writing an application that is database-intensive requires that you have solid database skills on your development team.

Although this approach is not common, project failure is very common. Not using this approach is helping to cause catastrophic project failures.

The bottom line is that if you are writing a database-intensive application, make sure you have someone who can spell Oracle, or keep your checkbook and 16-month calendar handy because you will need it.

I do want to concede that it is POSSIBLE to write good code in the middle tier.  I can imagine that if I do all of the following, I might be able to write code that even out performs the database:

·         bulk extract the data

·         lock it from being updated in the database

·         manipulate it

·         push it back

However, I have not seen this done in practice.  Every project that I have had to rescue required moving logic to the database.  It has NEVER been the case that I needed to pull things into the middle tier to make them run faster.

Also, to temper this position a bit, I do put things in the middle tier where appropriate.  We have used every aspect of the rich Application Development Framework - Business Components (ADF BC) at one time or another and it has helped the applications. But usually it is cheaper and faster to place as much as possible in the database.