Best Oracle OpenWorld 2008 quote so far..
WSJ blogger Ben Worthen on the HP Oracle Exadata Storage Server:
Oracle now has a device that is kind of like an iPod except that it is a lot bigger and a lot more expensive and not as cool.
"... priced at US$4,000 per terabyte of storage, plus the database license costs" Oh my.
read more and comment..
Premature Exultation
No better lesson on counting chickens...
read more and comment..
On context paths in Java EE
I was recently involved (tangentially) in an exercise to migrate a tomcat-based JSP application to Java EE packaging, which had me taking a fresh look at the concept of context paths and considering best practices for handling them.
When you package and deploy a Java EE web application, it has a context-root which effectively becomes the path on your application server that the application is available under. For example, the following module definition would setup MyApp to be available under http://server.domain/myapp/
<module>
<web>
<web-uri>MyApp.war</web-uri>
<context-root>myapp</context-root>
</web>
</module>
Context paths make it possible to host many applications on the one server as long as you keep the paths unique. As advised in Build to Spec! Part II:
Always specify a unique context root for every Web application you deploy to avoid naming collisions with applications already deployed.
It is possible to install an application with a context root of "/" but there are two considerations to bear in mind:
- Applications servers will usually have a default application already installed under "/" which would need to be removed first.
- The reason why the default application exists is to host resources that are not packaged as a web application (which may or may not be a concern, depending on what you are serving).
Problems arise when applications are coded with implicit assumption or explicit reference to the context path they will run under.
This is often the case - as I discovered - when migrating simple JSP applications to Jave EE packaging. Either the app assumes it will run from "/", or it has hard-coded paths under the root.
It can also occur in applications designed to be packaged as a .war or .ear file, if the developer assumes that the context-path will remain the same and does some hard-coded shortcuts. This breaks the Java EE separation of duties design, and prevents the system administrator from chosing to deploy the application on another context path (if, for example, there is a conflict with another application).
What the Specs Say
The JSR 53: JavaTM Servlet 2.3 and JavaServer PagesTM 1.2 Specifications define the context path concept, and some relevant API features.
Firstly there is getContextPath() which allows you to obtain the context path.
There's always been some doubt as to how sendRedirect() should behave though, but now that is cleared up in the 2.3 spec. From Servlet 2.3: New features exposed
And finally, after a lengthy debate by a group of experts, Servlet API 2.3 has clarified once and for all exactly what happens on a res.sendRedirect("/index.html") call for a servlet executing within a non-root context. The issue is that Servlet API 2.2 requires an incomplete path like "/index.html" to be translated by the servlet container into a complete path, but doesn't say how context paths are handled. If the servlet making the call is in a context at the path "/contextpath," should the redirect URI translate relative to the container root (http://server:port/index.html) or the context root (http://server:port/contextpath/index.html)? For maximum portability, it's imperative to define the behavior; after lengthy debate, the experts chose to translate relative to the container root. For those who want context relative, you can prepend the output from getContextPath() to your URI.
How to Retrofit Correct Context Path Handling
Migrating an application to Java EE packaging can be a it of a nightmare if url references are not nicely relative, and avoid any assumptions about the full path to the application.
Obviously, in this situation you probably can't avoid going in to clean up the code at some point.
But there are some tricks that can be used to delay that activity.
I've experimented with using servlet filters to do rewrites on the oubound HTML, and that seems to work fine. The filter intercepts all the output of the application, and can be used to fixup text/html or css using regex replacements, and even change the sendRedirect behaviour if desired. But it does introduce some overhead, and I wouldn't see it as a permanent solution. (see EnforceContextRootFilter-1.0-src.zip for all the lowdown on the servlet filter approach, including code you can use and adapt if it meets your needs)
read more and comment..
restful_authentication and OpenID with Rails 2
Note to self: Yes! managed to navigate the various OpenID resources for rails and managed to successfully setup OpenID with restful_authentication on Rails 2.1.
There are a few tricks to be aware of. Prompted by a question on stackoverflow.com, I thought I would post my notes here.
Installing restful_authentication
Usually, you will be plugging open_id_authentication into your app's identity management framework. One of the most popular - and the one I've been using of late - is restful_authentication.
Getting restful_authentication working seems to require a few tweaks however - at least for the latest version found up on github.
Firstly, I've had no success directly installing it using the plugin script like this:
ruby script/plugin install git://github.com/technoweenie/restful-authentication.git
Rather, I've had to manually clone the github repository and manually setup the plugin directory:
$ git clone git://github.com/technoweenie/restful-authentication.git
$ mv restful-authentication/ myapp/vendor/plugins/restful_authentication
$ rm vendor/plugins/restful_authentication/.gitignore
$ rm -fR vendor/plugins/restful_authentication/.git
Note that I'm cleaning up some of the git bits, and also changing the plugin directory name to use an underscore rather than a hyphen (Rails usually complains to me otherwise).
Setting up restful_authentication is then pretty straight-forward:
$ mkdir lib
$ ruby script/generate authenticated user sessions
$ rake db:migrate
Note: if you don't already have the 'lib' directory in your application, it must be created first, otherwise the generator will fail.
Installing open_id_authentication
Ryan Bates' Railscast on Openid is the best thing I've found to follow. Even though it was recorded with Rails 1.2.3, I've been able to successfully follow the tutorial with Rails 2.1.0. The only point to note is that for:
gem install ruby-openid
I installed 2.1.2, rather than the 1.1.4 used in railscast.
Installing open_id_authentication is then a doddle.
$ ruby script/plugin install open_id_authentication
Follow the Railscast from this point to integrate OpenID with restful_authentication.
Using restful_authentication on heroku
The plugin installation problems mentioned above also mean that you need to use a few tricks to get it working in a heroku-hosted application. I've found it best to clone your heroku app and add the restful_authentication plugin locally, and then git push it back to heroku when done.
read more and comment..