Thomas of Hookton and 1215, The Year of the Magna Carta
|
Bernard Cornwell is a master and commander when it comes to bringing alive European history from the last millenia. Where Patrick O'Brian has the sea, Cornwell has the land. I've read most of the Richard Sharpe novels, but I first encountered the grail quest series as audio books from audible. I must say that in combination with narration by Seán Barrett, I was absolutely hooked from the out. Together, they bring 14th century Europe to life like I have never heard before. Cornwell with his words that pump life into long dead stories, and Barret with his voice that just seems to call down through the ages. If only my 2nd form history lessons were like this. But how can history teachers brought up in the 1950's, using text books written by dainty scholars hope to convey a true sense of the times? 
It may look quaint in a tapestry, but battle with sword and bow is particularly brutal. But of course for the men of the time it was just all part of life. As Cornwell tells the tale of Thomas of Hookton, the grim reality of life leaps from the page with Barrett's voice. 
Seriously, the best way to "read" the grail quest series is to listen on audible. there are three volumes: |
|
A great companion read is 1215: The Year of Magna Carta
It is a fascinating - and less dramatic - study of England in the 13th century: the years of Prince John, the legend of Robin Hood and of course the Magna Carta. It was only after reading this, and having been embued in the era thanks to the Grail Quest audible recordings by Seán Barrett, that I finally got a true sense of the complex relationship between France and England after the Norman conquests of Britain.
And then there is the Magna Carta. Probably more significant as a legend and ideal than an actual statement of rights. In its time, it seems to have been seen by some as a scandalous concession to the masses. Even Pope Innocent III condemned the charter as
..not only shameful and demeaning but also illegal and unjust, thereby lessening unduly and impairing his [the king's] royal rights and dignity
read more and comment..
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..