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/
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.
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.
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..
|Peopleware: Productive Projects and Teams by Tom DeMarco and Tim Lister is often cited as the classic software development management text; one that rightfully puts the focus on people. |
So I had heard about it long before finally getting around to reading it recently.
It is a really good collection of insights, suggestions and anti-patterns that makes a great read, and good food for thought. Especially because it sweats the little things, like office furniture, interview techniques, and the evils of the telephone.
Management by Hysterical OptimismHaven't we all seen that in action at some time? (unfortunately)
The authors do however take a little liberty in claiming the Hawthorne effect says people perform better when they're trying something new. Which I believe to be true, but isn't exactly what the Hawthorn effect is (people will be more productive when appreciated or when watched).
My report is not all good however. There more I read into the book, the more I felt the authors' advice was biased towards a certain ideal organisation that is I think by no means universally applicable.
In short: workers all strive to be master craftsmen; they provide their own motivation, vision and goals; management is best advised to just provide the creature comforts and get out of their way.
While many may relate to this (personally I do too), as a general theory of management I think it is a crock. In the 60's they would have called this 'flower power'. In the 50's it would have been labeled a 'communist conspiracy'.
No, I think the real world is a little more complex than that. But Peopleware nevertheless delivers a great deal of practical advice.
Seven False Hopes of Software Management
My favourite "list" from the book...
- There is some new trick you've missed that could send productivity soaring
- Other managers are getting gains of 100% or more
- Technology is moving so swiftly that you're being passed by.
- Changing languages will give you huge gains
- Because of the backlog, you need to double productivity immediately
- You automate everything else; isn't it about time to automate your development staff away?
- Your people will work better if you put them under a lot of pressure
With a preference for the decimal system, I have the temerity to add:
- Build it and they will come!
- We just need a SOA architecture!
- It's going to take too long/cost too much, so can you revise your estimates?
read more and comment..