Sigh.. dealing with Oracle again

I'm currently attempting to install Oracle's crappy Access Manager which uses InstallShield, which is also crappy (well on Linux anyways). So it keeps asking me this:

The product that you are about to install needs to be owned by a dedicated
user. Only root or the dedicated user may be able to start the service. Most
of the time the server is run as `root' or `nobody'.

Enter the username the Access server is running as [nobody]
Enter the Group for the above username [nobody]

To which I give a valid user and group, and it gives me:

Sorry, invalid user `nobody' or invalid group `nobody'.
Please check and enter again.

I've tried a plenty of combinations or valid users and groups, even the sid and gid and nothing works.

To make things worse, most of the Oracle site seems down today. All of the books I need and some downloads all return 404. It amazes me that Oracle can stay in business while eating their own dog food. I figured they would need to run software by a competent vendor.

At least this is getting me nice and riled up for the terrible Oracle love-fest that I'm going to next week.

Oracle site is down.. again

I'm doing some research on storing geoencoded information. I don't have a hard requirement for this, but we want to store some geo information with addresses and "we might as well do it right". So I found some information on Oracle's Spacial product, but from that documentation discovered that the Spacial product is over kill and the the database already has what we need. Apparently the database comes with a way of storing geo information and it is called Locator. But alas, I can't figure anything else out because Oracle's site is down.

This time I know it is not the office's internet since I'm sitting in a coffee shop (no not Starbucks).

Oracle throws its money around... Goodbye BEA

Last week, Oracle finially got the number that felt right to BEA to get them to walk away from their business. Sad to see BEA go... each additional player in the JEE camp is a welcome addition to the idea of choice and best fit. I'm really writing because I read an article that sums up the situation AMAZINGLY well, and not because I have any insight at all as to what will happen to OC4J, or Oracle, as this change moves its way through the system.

This article on TheServerSide is a letter from GigaSpaces to its BEA Weblogic customers.. informing them of the evil that has come down upon them... and it's 100% true.. minus the advertising part of it. So, for those of you that are on OC4J and have a choice to switch, or are using JDeveloper to do contract work and suggest your clients use OC4J.. read this.. and think about those decisions again.

The people I work with, overall, don't seem to share this vision.. and well.. neither does my client. But, its a fact... heavy weight clustering and tooling is the WRONG way to do enterprise development... and the private industry is quickly realizing it...

Also, in other news of big companies forcing little guys to do what they wish; microsoft is FORCING the IE7 update to all systems... meanwhile, I dont think many of the websites I've worked on have javascript that'll work on IE7... thats a lot of retooling because someone doesn't want to support or give out the code to the browser that was originally integrated on.

Invalid Portal Session

Looks like Oracle does eat their own dog food (since it doesn't work). This is the latest error I get from the Oracle site.

An error was encountered while processing your Portal request, because your portal session is no longer valid. You have been logged out and you will automatically be redirected to the OracleAS Portal home page in 30 seconds. Click OracleAS Portal home page to go directly to the OracleAS Portal home page, or if your browser does not automatically redirect you. If you continue to have problems while accessing OracleAS Portal, close all your browser instances and try again.

Wow.. I actually found someone with the same issue!

What's probably the most frustrating thing about Oc4j is that its impossible to find someone else with the same experiences. Shit, finding a tool that even mentions deploying onto OC4J is downright astounding.

OC4J is such a troubled tangled web of random error messages that searching for things generally comes up with one or two hits, that have nothing to do with what you're doing. So, I was shocked to find someone else with a problem that I recently became confronted with, and have yet to solve. (And, in fact, its stopping one aspect of my application from being self-managed... *cries*... develops have to actually touch the production database to fix something that it can fix itself.. *cries*)

ACayci is an unfortunate soul that has attempted to allow a JMX Operation to do something with JNDI through OEM, and has hit upon the nasty "NO JNDI FOR YOU!" exception.

Its a scary error. Cause, JMX should invoking the classes under the same classpath that the application is deployed in.. i mean.. OEM is getting a list of MBeans FROM that class loader, right? maybe?

DnlCYan replies with what I'll summarize as a "haha!"... basically responding that OC4J is rather particular about having every orion specific deployment description file inside of the application's ear/war.... which leads you down the path of finding out just how many xml documents you need to now version and hack into your ear... there is a freaking reason the ANT Ear task only expects an application.xml... its all that should be there.


So, in my case, I'm tempted to move the connection pool into my application as opposed to looking up through JNDI as the work-around. Shit, I'm sure the commons connection pool is even better than what OC4J provides...and I can change it at RUNTIME to allow more or less connections in the pool.

I wont drag this on, but, if someone has been able to actually get OEM's crazy JMX runtime to discover JNDI things (specifically container managed database connections)..... Well, I dont know what to tell you to do.... there should be a freaking wiki on it... but.. *sighs*

Where do I write my bug report? Shit, I can write a verifiable test case in about an hour...

Package Dependencies

The thing that finally got me to start this blog was how I wasted pretty much all of last week (short week) attempting to get an Oracle product working. While I'm not going to go into all the details in this one post, I would like to touch on how impossible it is to even get started using Oracle products.

Most complex software packages come with a system of managing dependencies and internal modules. For instance, different flavors of Linux have a variety of managers/packagers (RPM, Yum, YaST, Deb, emerge, etc.) to help both the user keep up-to-date, and to help support figure out what is going on. Java, of course, comes with the venerable Jar, and Maven added widely used Maven Repository. Oracle seemingly has nothing. In order to do anything you need to download 600M+ of monolithic whatever and install in one big fat extravaganza. "Upgrading" takes on a similarly grandiose spectacle, usually involving a few DBAs and a weekend. Other then that, it is a seemingly never-ending parade of patches that have no relation to anything else in the system. No wonder anyone who thinks about Oracle too long needs an obnoxiously expensive support contact (that ends up doing nothing).

So what does this mean for the developer? Well first, managing development becomes difficult. Any developer would be insane to run the entire Application Server on their dev box. At least any developer who wants to get things done. Therefore, the Application Server goes on a shared development server, and tada.. we are back to timesharing the dev server like in the mainframe days. Well, not quite that bad. At least there is OC4J Standalone to "save" us. Which, btw, in very inconvenient times decides to behave differently from the full install for no reason. This is even further evidenced by the fact that most Oracle products don't install on Standalone, but need the full Application Server. How do our apps have a chance if even Oracle's don't.

It also means that I can't just download the product within the stack that I need and develop against it. In consuming a small API, which is promoted on the Oracle site like it is its own product, it must be extracted from a 600M+ download and then Installed just to get the jar files you need. This one took me almost a day. If I was allowed to have chosen wisely, I could have had the integration with that product done already instead of fiddling with an installer for a product that does not even need to be installed.

Unreachable Host

I'm actually trying to read OC4J Expert Opinions right now but am witnessing how hard Oracle fails by their lack of uptime. I cant be the only one that cant get to their website. Anyway, I was going there because Shay Shmeltzer responded to this article on the new preview 11g release of Oracle's Development Environment, stating, "So how about reading what analysts like Gartner, Forrester and others have to say about this?".. which pisses me off because I don't know who Gartner and Forrester are...

But, alright, small think time, Isn't the point of a standards based server so that you could switch as you saw fit? Maybe OC4J is great for its session bean handling (just a stab.. I dont know what its great for) and you notice through a 'normal' test that it seems pretty damn stellar, wouldn't you switch, regardless of what anyone says? Am I the only one not understanding why a platform built out of the idea of simple integration has such a hard time of moving from server platform to server platform?

The project I'm on right now seems to have the idea that there is no reason to test the waters with other servers... even when other projects have to basically rewrite entire aspects of their projects just to deploy to OC4J... Isn't it worth a days work to see what the fuss is about.. why would there be 10 different JEE containers if they all were exactly the same?

And isn't it really a product of the operational requirements to pick the features of an application server that works? SNMP support, scaling to certain hardware limits, ease of use, ease of upgrading, ease of clustering, performance on SPECjAppServer, fitting to the architecture of the application(s) deployed on it. Is it crazy to expect my operations people to understand when I say JMS queue that they should know how this effects the deployment? the network? the server load? Certainly if I said Database they have an idea of how to make a production system work.. is Application Server any different?

Anyway, I'm just ranting now that I cant get to oracle.com.... OH! and wishing my ops people would actually have an interest in middle-tier/application server system architecture and rather than saying "you can switch application servers because we need training" they'd say "we really dont want to loose our oracle cluster management console" or "We've seen cpu loads drop by 10% with Tomcat over the current application server software, which reduces our heating & electricity costs by $200 a month and increases response times by a half second on each request during normal business hours.. lets switch."