Re: when Oracle9i database supports J2EE 1.3 (or even 1.4)?

Sander <sander_at_example.com> wrote:

Note: I'm redirecting followups to comp.databases.oracle.misc, since I think that the discussion that follows is not much server-related.

> etechweb_at_yahoo.com (Sebastiano Pilla) wrote in
> news:1fb9hxa.5ih8v4mh70kN%etechweb_at_yahoo.com:
> (...)
> > Oracle bundles
> > it with an HTTP Server (Apache, but with broken basic
> > authentication on Win32),
> (...)
>
> Do you have a bug number for this?

Sorry, I don't. I've simply deinstalled the Oracle HTTP Server and installed the Apache HTTP Server from apache.org. I'll try checking MetaLink in the following days to find out a bug number, however the problem was that the server tried to match the passwords but didn't encode them in Base64 before.

> > Not only I'm running a production site on OC4J, I really hope that
> > it gets even better so I can use it elsewhere: I find it extremely
> > fast, robust, and not much resource-hungry. I'd be much happier if
> > Oracle would drop from iAS bloatware such as Portal (and stop
> > sending salespeople to promote it...)
>
> What's the problem with Portal? There are many people using Portal even
> in big environments.

I first met Portal last summer, when a group at my company was preparing a demo for a project that was about to start. Previous to my involvement, Oracle's 9iAS had already been chosen as the environment for the project, and there was a strong push towards Portal.

I and my colleagues however had a terrible experience in preparing just a handful of pages, even with the assistance of 2 consultants from Oracle: indeed the experience was so bad that I decided to stop any development in the Portal environment and to focus on OC4J instead.  

I think that Portal has many problems, but trying to summarize (regarding 9iAS 1.0.2):

1. Non-existent (or very weak) separation of logic from presentation This is a killer for us. The running model in Portal is (oversimplifying) that an URL requested from a browser gets mapped to a stored procedure: if you don't use the standard features (so-called "portlets"), you have to write the procedure so that it outputs HTML to the browser. I think this is extremely bad because it clutters the business logic within the procedure with the layout code that displays the data: if the customer asks for some layout changes, you shouldn't have to touch code which contains business logic. At the extreme, you may have to have at least 2 people, a developer and a page author, trampling each other on the same portion of code.

I found mentions of a templating engine, buried semi-deeply on Technet, but at the time it was unclear how much powerful it was, and none of the consultants from Oracle could tell us something about it.

2. Rigid layouts
Point 1. above is relevant when you have to implement a moderately sophisticated page layout. It turns out that, well, you can't do that. A Portal-generated page is made up of one or many portlets, and each portlet "lives" into one HTML table. The enclosing table is generated from Portal itself, and therefore page authors can do very little with respect to the overall page layout.

3. Some features are clumsy to use from Java and JSP We tried to overcome the abovementioned problems by switching our custom code to Java (the other language besides PL/SQL supported by Portal). However, using some features, such as the Single Sign-On offered by the Login Server component, from Java (and JSP) code, isn't so straightforward.

4. Editing environment are HTML forms
Back to using HTML portlets, then. Portal provides an editing environment that has the possibility IIRC to store different revisions of the same code in the database. Unfortunately the editing environment is made of HTML forms: after some frustration, we ended up using an external editor and copy-paste the code. And eventually one of our HTML authors had to write a long portion of HTML and JavaScript code, to display a menu, but when he tried to save the code into the database he got back the error that the value was too large. Some experiments showed that there was a 32KB limit for the code entered in those textareas, we speculated because the text was passed as a varchar2 parameter to a stored procedure.

5. Managing different environments is problematic Our normal practice is to have a development environment, a staging environment (for acceptance testing, integration testing, etc.) and of course a production environment. Efficiently and reliably moving our work between those environments is almost important as developing it. We found that Portal had no officially supported method for moving portions of code between environments, and that also exporting and importing the Portal schemas via the provided scripts didn't work 100% of the time.

In addition to these things, there were others minor annoyances, such as general slowness both in the development pages and in the end-user pages. However points 1 and 5 above really killed Portal for this project. One might say that I'm dissing Portal just because it wasn't the right solution for our problem, and I concede that for some other problems it may be the right solution. I still think however that what I've found are fundamental issues with the product, not minor things limited to our situation.

Sorry for the length of this post, I hope it wasn't too boring. It would be nice to know if newer Portal releases have solved some of its problems. Unfortunately my experience was so bad that I've simply stopped paying attention to its further developments.

Sebastiano Pilla Received on Tue Apr 30 2002 - 15:51:34 CDT