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).
Thursday, January 31, 2008
Monday, January 21, 2008
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.
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.
Tuesday, January 15, 2008
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.
Monday, January 14, 2008
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...
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...
Thursday, January 10, 2008
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.
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.
Wednesday, January 9, 2008
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."
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."
A Child application may have already started this instance
There is this weird error message that happens when starting a container on OC4J 10.1.3.3.0 when things are out of whack, and it isn't exactly the most friendly or informative error message. Its the one you see as the title of this blog message above you.
The other day, we were hitting a problem with our application deployed to OC4J 10.1.3.3.0 where it would spin and spin and spin and finally throw out a 500 internal server error, the application, mind you. Which is fine, just hiding the real error message.. which I asstutely knew how to get more information from by going into $ORACLE_HOME/j2ee//applications//_web/orion-web.xml and adding development="true" to the orion-web-app xml tuple, which, of course, you'd know to do anyway.. right.. 'cause you wrote an orion-web.xml for your war too, right? Anyway... I had my operations person restart the ENTIRE MACHINE so that we could try again and get the real error message to find I was hitting an out of heap space exception. Ok, thats not good. So, what'd I do? I upped the heap space.
ERROR ERROR.. Now I cant start my container.... But, when you cant start your container, you cant administer that container.. which means I couldn't change my settings back to the way they were to see if that fixes the non-starting issue. Now what?!
I ask my operations person to restart the entire machine a couple of times and then I start building a new container. After about 20 miuntes of configuring a new container, look who decided to start.. on his own.. and without telling me.. (c'mon.. and ajax notification wouldn't have killed ANYONE to add in..) the container that wouldn't start.. had started..
So I go back in, hit the same problem.. and decide to bump the max heap size up some more.. "what could possibly be going on? this is weird", I thought. Rinse and Repeat.. But, this time, the container wont start to save its life.
I walk back down to my operations person and say "Hey, Something is weird, can you try and start the container?"
"Yeah, sure, one sec"
>opmnctl startall
>........
>Container has failed to start due to too low starting heap size.
"WHAT!?"
How in the world does that not get validated on the front end.. how in the world does an error message reported by the backend start-container job not get propogated to the front-end application deployment console..
And thus, 4 billable hours of my client's money was wasted because of just a minor, intsy wintsy bug in the container.
The 500 internal server error was totally OUR codes fault.. we had an infinite loop, which was easily debugged once I could get around the mayhem of 'Is this container even running correctly?' to realize my code was in fact to blame.
Open Source Rant
Am I entering a bug? Nope. Am I fixing the problem? Nope. I'm not. Just another drop of personal experience that'll make me a better OC4J user, and not make the product any better. If I hit this problem using any one of several openly developed servlet/JEE servers you'd better believe I'd immediately open a ticket and followed through with a passion to make sure no one would hit the same frustration. I mean, seriously, ONE LINE OF VALIDATION WOULD'VE SAVED ME... Or maybe its the other way around, the openly developed tools would have completely skipped a rule that looked anything like this because of how unreal it really is.... who thinks of these kind of rules.. and if it's backed up by actual research, wouldn't their be an OC4J memory management & garbage collection tuning tutorial that would outline the things I need to know about who OC4J does to make my life 'easier'?
The other day, we were hitting a problem with our application deployed to OC4J 10.1.3.3.0 where it would spin and spin and spin and finally throw out a 500 internal server error, the application, mind you. Which is fine, just hiding the real error message.. which I asstutely knew how to get more information from by going into $ORACLE_HOME/j2ee/
ERROR ERROR.. Now I cant start my container.... But, when you cant start your container, you cant administer that container.. which means I couldn't change my settings back to the way they were to see if that fixes the non-starting issue. Now what?!
I ask my operations person to restart the entire machine a couple of times and then I start building a new container. After about 20 miuntes of configuring a new container, look who decided to start.. on his own.. and without telling me.. (c'mon.. and ajax notification wouldn't have killed ANYONE to add in..) the container that wouldn't start.. had started..
So I go back in, hit the same problem.. and decide to bump the max heap size up some more.. "what could possibly be going on? this is weird", I thought. Rinse and Repeat.. But, this time, the container wont start to save its life.
I walk back down to my operations person and say "Hey, Something is weird, can you try and start the container?"
"Yeah, sure, one sec"
>opmnctl startall
>........
>Container has failed to start due to too low starting heap size.
"WHAT!?"
How in the world does that not get validated on the front end.. how in the world does an error message reported by the backend start-container job not get propogated to the front-end application deployment console..
And thus, 4 billable hours of my client's money was wasted because of just a minor, intsy wintsy bug in the container.
The 500 internal server error was totally OUR codes fault.. we had an infinite loop, which was easily debugged once I could get around the mayhem of 'Is this container even running correctly?' to realize my code was in fact to blame.
Open Source Rant
Am I entering a bug? Nope. Am I fixing the problem? Nope. I'm not. Just another drop of personal experience that'll make me a better OC4J user, and not make the product any better. If I hit this problem using any one of several openly developed servlet/JEE servers you'd better believe I'd immediately open a ticket and followed through with a passion to make sure no one would hit the same frustration. I mean, seriously, ONE LINE OF VALIDATION WOULD'VE SAVED ME... Or maybe its the other way around, the openly developed tools would have completely skipped a rule that looked anything like this because of how unreal it really is.... who thinks of these kind of rules.. and if it's backed up by actual research, wouldn't their be an OC4J memory management & garbage collection tuning tutorial that would outline the things I need to know about who OC4J does to make my life 'easier'?
What am I doing here?
I too, have had the not-so-much pleasure of working with the Oracle line of JEE products. And, day after day with error after unimaginable error, I rip hair after hair out of my metaphysical head. Day after day I hear about all the political reasons for why Oracle is the smart choice, and bang my head on the FACT of how incompetent the team of monkeys that brought these miserable piles of trash into fruition really are... and the fucking imbalance of these two thoughts and the disconnect from all things right and moral destroys every ounce of my being and rips my passion of doing things correctly for my clients into a super-state of non-existence. WHAT AM I DOING HERE?! is all I can seem to muster up to combat such a complex and unimaginable catch of states.
I sit, day by day, and watch other projects grow and prosper because they are built on a foundation of great tools, great ideas, and an almost superhero knowledge that nothing can stand in their way. And it literally is a daily thing... projects turn corners everyday because they solve problems.... and move past them. Oracle, is the impassable corner in JEE.
It's like a virus too, it starts simply with purchasing what could only be the most expensive database system ever (with probably good reason.. who can afford to support such a massive sack of failure (i mean, they are so dedicated to patching!)) that transforms into the succubus of "We wanna do Java development!".
I'm not attached to Java, JEE, Servlets, Java GUIs or any of that.. so, I'm not trying to represent that ONE product or one stack is the best because of partiality.. I'm actually quite fond of C++ & PHP development... but, hey, Java is a GREAT language to own.. and I'm not going to fight it, I have to agree.. Enterprise development really has gained leaps and bounds because of how portable, pluggable, and preferable to all other languages for ALL aspects of software system development.
So, I am joining the ORA-01092 quest of cataloging, and exploring the SUCK that is working with this rather interesting class of product.
I sit, day by day, and watch other projects grow and prosper because they are built on a foundation of great tools, great ideas, and an almost superhero knowledge that nothing can stand in their way. And it literally is a daily thing... projects turn corners everyday because they solve problems.... and move past them. Oracle, is the impassable corner in JEE.
It's like a virus too, it starts simply with purchasing what could only be the most expensive database system ever (with probably good reason.. who can afford to support such a massive sack of failure (i mean, they are so dedicated to patching!)) that transforms into the succubus of "We wanna do Java development!".
I'm not attached to Java, JEE, Servlets, Java GUIs or any of that.. so, I'm not trying to represent that ONE product or one stack is the best because of partiality.. I'm actually quite fond of C++ & PHP development... but, hey, Java is a GREAT language to own.. and I'm not going to fight it, I have to agree.. Enterprise development really has gained leaps and bounds because of how portable, pluggable, and preferable to all other languages for ALL aspects of software system development.
So, I am joining the ORA-01092 quest of cataloging, and exploring the SUCK that is working with this rather interesting class of product.
Impressions on using Oracle's middleware stack
After another week lost attempting to make an Oracle product work, I've finally decided to rant about it publicly. As a software developer (mostly J2EE) I have had the misfortune of having the Oracle Application Server stack "picked" for me by my clients, and it hurts. I think it must be a run of bad luck, I have been using it since Oracle purchased the container from Orion and hadn't even started calling it OC4J yet. 1.0.2.1.0 was one the first in a long and complicated string of releases, and with each one I held hope that it would get better. Unfortunately, it has not. How Sun lets Oracle get away with calling it a J2EE container is beyond me. And thats just the container...
As for naming this blog.. I thought that some sort of oracle error seemed appropriate. Especially since there is no avoiding the cryptic messages that you have to go to a non-oracle source to decode. Here are a few that I looked at (from the "Frequent Oracle Errors" section on ora-code):
Hopefully this will become a place where developers that have been forced to use the Oracle stack can come to commiserate on using this decrepit platform. Some candidates for good starter topics may be:
As for naming this blog.. I thought that some sort of oracle error seemed appropriate. Especially since there is no avoiding the cryptic messages that you have to go to a non-oracle source to decode. Here are a few that I looked at (from the "Frequent Oracle Errors" section on ora-code):
- ORA-01033 - ORACLE initialization or shutdown in progress
- ORA-04068 - existing state of packagesstringstringstring has been discarded
- ORA-01092 - ORACLE instance terminated. Disconnection forced
- ORA-12500 - TNS:listener failed to start a dedicated server process
- ORA-00097 - use of Oracle SQL feature not in SQL92 string Level
Hopefully this will become a place where developers that have been forced to use the Oracle stack can come to commiserate on using this decrepit platform. Some candidates for good starter topics may be:
- Why the Oracle XML parser (parserv2.jar) is the most annoying and worthless parser ever
- How annoying it is that OPMN (Oracle Process Manager N-something) can't manage what it is supposed to.
- How much time is wasted when OEM gets in a bad state and you need to create a new container for the N-th time.
- Downloading things from oracle (why do I need a 700mg file to do anything?)
- Why can't Oracle make the stupid Universal Installer universal?
- Why the JAZN (Oracle's JAAS implementation) totally sucks (most of this was fixed in 10.1.3)
- What is it with Oracle numbering anyways? OC4J 9.0.2 was virtually the same as 10.1.2, but 10.1.3 was almost a total rewrite.
- OC4J's terrible classloader
Subscribe to:
Posts (Atom)