UrlBlogGrey

I've been working on a Java-based web application titled "Getting Things in Order". It's a project-planning application that uses a lot of the concepts described in David Allen's geek-friendly book "Getting Things Done". I'm using a lot of open-source tools in the process: Eclipse, Apache Tomcat, Linux, the Spring Framework, and many others.

Some of the features I've got in place are:

• Uses a relational database (I'm using MySQL) to store application data.


• Supports multiple users with separate project/action data.


• Administration of users, and the designation of users capable of administration duties.


• The ability to create, edit, and delete Projects (composed of one or more Actions).


• The ability to create, edit, and delete Actions, which are atomic tasks.


• A main page that summarizes a user's Projects and the next Action for each.

I've made a lot of progress in the last two weeks, and it wouldn't have been possible without the assistance of the Spring Framework. It does a wonderful job of simplifying the creation of complex websites. I hope to incorporate AJAX behaviors soon with the aid of the Direct Web Remoting (DWR) library.

Posted by Scott at 6:47 PM | Permalink

I installed Firefox 2.0 Alpha 3 ("Bon Echo") last week on our Macs and have been very pleased with the release. It has shown to be very stable and efficient. My favorite new feature is the inclusion of a Google Suggest search box in the upper right where a simple search box lived previously. Google Suggest is a great application of the AJAX web design strategy that enables completion of search phrases while typing with phrases used in similar searches. Having the convenience of this search box in the browser is very nice.

As a side, I posted just in time with 2 minutes of battery power left! Type, quickly!

Posted by Scott at 8:02 PM | Permalink

I recently wrote about the intermittent behavior of the brake light switch in my 1998 BMW 323is. So, I ordered a replacement part from Bavarian Autosport at the reasonable price of ~$18. The part was automatically identified for me based on information I supplied while navigating the site. So, I assumed it was correct. Unfortunately, this wasn't the case.

There are two designs for the brake light switch in BMW's E36 series: a four-pin switch, and a two-pin switch. I had ordered the two-pin switch when my car requires the four-pin switch. I'm a bit disappointed by this, and hardly consider paying the return shipping costs worthwhile for a part that cost less than $20. So, I ordered the correct part from Pelican Parts instead. They also feature an excellent write-up on how to perform the repair.

I think that doing your own auto repairs is great in non-emergency situations. In my case, I can stand to wait another week because the light failure is a rare occurrence. If I were to take the car into a garage, it would likely cost me upwards of $75 and I wouldn't learn anything about the workings of my car in the process. I understand there is a degree of inconvenience and risk involved in working on one's car, but I think that having a knowledge of how things work helps cultivate an appreciation for technology that we'd otherwise take for granted.

Here are some things I learned:

• A lot of trash can collect in the foot-well of a car.


• Laying inverted in the driver's seat of a sports coupe can yield a mind-altering head-rush.


• It's a good idea to disconnect wires from interior panels before attempting their removal.


• The PowerBook gets good WiFi reception in the garage. Crank up iTunes and let's party!

Posted by Scott at 2:17 PM | Permalink

I've been reading the international best-seller "The Da Vinci Code" in anticipation of the up-coming film. I had tried reading the book in 2003, but bailed out after about 200 pages. I get hooked by story lines through the usual literary devices: character development, intrigue, etc. For some reason, "The Da Vinci Code" didn't hook me, although it has hooked millions of people world-wide.

Although I was raised with an awareness of the Bible and Christian beliefs, I have never considered myself a Christian. This is mostly because I have had difficulty believing the stories in the Bible. And, I tend to look at religion with the same skepticism I apply to the rest of the world. I have long believed many of the theories that "The Da Vinci Code" proposes: that Jesus Christ was a mortal man, and that the stories in the Bible have been distorted by the Church to suit their interests.

I suppose that for someone who has long assumed that the Bible has the same form today as it did a millenia ago, "The Da Vinci Code" puts forth some ground-breaking material. But for me, it's simply adding twists to what I always thought of as collection of stories. I think this is why the book didn't have the same shock-factor for me as it did for many Christians.

I think that the primary difference between stories and scripture is that stories permit customization, but scripture is gold. Their mission is often the same: to entertain, educate, and inspire. But how is scripture made?

Posted by Scott at 10:19 AM | Permalink

Plug-ins extend the capabilities of Movable Type when formatting and associating entries in a site. I've been looking for a plug-in to format Java source code that I occasionally post on my site, since source code can often be difficult to read without language-sensitive formatting.

While browsing the Movable Type plug-in directory, I came across the MT Colorer plug-in. It uses the colorer library for the Perl scripting language to format designated sections within a Movable Type entry. Perl is the language that the Movable Type software is written in, so the MT Colorer plug-in takes advantage of other facilities within Perl to make text formatting simple.

The MT Colorer installation was simple, though I had to download and install the Syntax::Highlight::Universal Perl module that's required. This was possible only because I have shell access to my web hosting provider and know the machine architecture (Linux x86) used by the web servers. People without shell access must request that their hosting provider install the module if it is not already present.

Once the installation was done, I reformatted several of my previous posts and have been pleased with the outcome. As with all Movable Type plug-ins the work is performed at the time of publishing, so all content is rendered up-front. Here's an example, in the form of a simple Hello World! Java class:

public class HelloWorld
{
  public HelloWorld () { }

  public static void main (String [] args)
  {
    System.out.println("Hello, World!");
  }
}

Posted by Scott at 9:25 PM | Permalink

For the last two years, there has been an intermittent problem with my 1998 BMW 323is where the car computer will report a "brake light circuit" error. On numerous occasions I've parked the car, checked the lights, and seen nothing wrong. The bulbs all function, and the brakes themselves are in excellent condition (I just had all-new pads and rotors installed a month ago).

I googled the problem a bit recently and learned that the term "brake light circuit" extends to the front of the car, and not just the back. Apparently there is a common problem with the brake light switch located in the driver's footwell near the brake pedal. When the pedal is pressed, the switch is triggered and the lights come on. If the switch is broken or intermittent (my case), the lights do not come on at all. This is pretty scary since it suggests that other cars aren't seeing my brake lights come on at times.

I ordered a new brake light switch (part # 61 31 8 360 420) from Bavarian Autosport for about $12 + shipping. There are some good repair how-to's on the web. I'll be receiving the part on Monday and will try to do the repair that same day. Driving with faulty brake lights in heavy traffic can be pretty disturbing.

Posted by Scott at 8:27 AM | Permalink

This presentation focused on NetBeans 5.5 as a tools-platform for Java EE 5. I really dislike presentations like this one because they draw in people interested in Java EE 5, but the presenters have the goal of advertising their tool or platform. If I wanted to be sold something, I would have gone to the Pavilion to hang out in the vendor booths and score some free stuff.

The only interesting part was hearing about what's going to be present in Java EE 5:

• regular POJOs with annotations instead of deployment descriptors


• incorporation of JAX-WS technology for web services


• dependency injection, a la Spring


• better default behavior & configuration (huh?)

I've got mixed feeling about annotations because they have the ability to pollute the source code with deployment information. And, if the deployment information changes in the generated descriptors, they become out-of-sync with the compiled code.

Posted by Scott at 9:21 AM | Permalink

AJAX borrows heavily from Dynamic HTML (DHTML), and was actually introduced in 2002 as part of Mozilla 1.0. AJAX is JavaScript using DHTML to dynamically render a web page with content obtained asynchronously from a remote server transparently to the user. This can be triggered by something like dragging the mouse, as in Google Maps.

The XMLHttpRequest (XHR) used in JavaScript functions is the backbone of AJAX. A quick demonstration showed why the XHR requests should be handled asynchronously using callback functions registered with the browser. Use of synchronous functions caused the browser thread to hang until a response was obtained by the server, which could result in a really bad user experience.

The presenters inisisted that applications like Google Maps are actually fairly simple UIs to build because of AJAX. They were actully able to come up with a clone of Google Maps in merely 3 hours.

There are a number of tools available for browsers like Firefox that use AJAX to improve the browsing experience. One such tool is GreaseMonkey, which allows users to inject AJAX content into any web page. For example, you could inject AJAX content into an Amazon page in order to view competitors prices or related information on the web.

Debugging DHTML can be extremely difficult since the content of the page can change at will. So, it's valuable to have tools like the DOM Inspector present in the Safari and Firefox web browsers. This will allow you view the HTML document graph in real-time, regardless of how the page looked when transmitted over-the-wire.

Posted by Scott at 9:01 AM | Permalink

This presentation focuses on the upcoming JetBrains product "Team Server".

Team Server seeks to make development teams more productive. It integrates with IntelliJ, web browsers, version control systems, and agents. Agents offer an extension of Team Server to provide additional build services (i.e. distributed builds, etc.).

The browser interfaces use AJAX to provide real-time status of the build. It looks a lot like CruiseControl, but with a much more polished interface, IntelliJ integration, and support for agents that can extend the Team Server capabilities.

The Agents feature is what differentiates Team Server from the competition. It introduces the concept of the Build Grid, which is already available in other build systems (i.e. Apple's XCode with GCC). Because there are usually more check-in than builds, the build grid offloads builds to separate agent nodes.

An interesting build-related feature is delayed check-in, which addresses the problem of the 5 o'clock check-in. When a developer commits their changes before learning the built results, it could negatively affect the productivity of local or remote team members. A delayed check-in states that the build system will delay check-in until it has verified that the build succeeds. No check-in will be done if the build fails.

Build notifications are often ignored by developers, not because of lack of concern, but because of their sheer volume. Suggestion is to e-mail only on failed builds, builds with my changes, or if no one is responsible for failure (i.e. scheduled weekly build).

Another neat feature is the ability to indicate ownership of a build failure by "taking responsibility." This indicates that the problem has been acknowledged and is being addressed. This capability is current missing in tools like CruiseControl.

Instant Messaging is coming to IntelliJ, too. It relies on the Jabber XMPP communication protocol, which is also used by NetBeans and other IDEs.

The speaker, Dmitry Jemerov, did an excellent job of presenting.

Posted by Scott at 8:58 AM | Permalink

Goal is to take an arbitrary Spring application and deploy it in a cluster without focusing on a clustered deployment.

Presented possible solutions using JMS or JCache to synchronize client sessions and data across multiple JVMs/Servlet containers. Argument is that the VM, or application server facilities, should coordinate cluster operations transparently to the application. Also, the serialization behavior in the Java language has traditionally required entire object graphs to be synchronized in a cluster whenever a single attribute in an object graph is changed. This is incredibly inefficient and should be avoided.

So, how does Spring help us solve clustering? Terracotta, using Spring, permits the injection of clustering facilities into clustered applications at runtime. It turns the Spring ApplicationContext events into distributed reliable events. Shares JMX states, and Spring Webflow's page flows. All of this is managed declaratively through the Terracotta XML configuration file.

This sounds really interesting, and the Spring ApplicationContext seems like an ideal point for synchronization. It's unfortunate that the presenter did such a poor job structuring the session (30 minutes on clustering solutions that don't work).

Posted by Scott at 8:57 AM | Permalink

JConsole is a valuable tool for obtaining information about interactive and non-interactive applications. MBeans are always present in the JVM - JMX and tools driven by JMX (i.e. JConsole) are just used to harness the information they provide.

MBeans hookup attributes, notifications, and operations. Mustang (Java 6) allows you to connect to any Java process on the local machine, regardless of whether it was started with JMX configuration options.

There is a challenge in connecting the JMX MBeans in the JVM and the runtime objects associated with your application. Example: adjusting a cache size at runtime using JMX. Here are the speaker's identified methods of establishing this connection.

Method 1: Information Grabbing
MBean consults global fields or methods. This is the simplest technique, but violates modularity. If the MBean can see the object it needs, then so can anyone else.

Method 2: Information Shoving
In this case, the cache object registers itself with the JMX server when initialized. The downside is that the cache class becomes "polluted" with JMX-aware code. An additional downside is that registering an MBean of an instance in the class' constructor can lead to race conditions.

Method 3: Quantum Entanglement
Lots of MBeans can become "entangled" whrough their registration mechanisms. This is bad.

Method 4: Dependency Injection
Borrowed from other technologies like the Spring Framework. An XML or similar configuration file can be used to inject the cache object dependency into the MBean. Spring can be used to accomplish this. So can Java 6 (Mustang), which supports dependency injection via annotations.

Method 5: Aspect-Oriented Programming (AOP)
An aspect can be used to link the MBean and cache class instance. This, too, can be accomplished using the AOP capabilities of Spring. The class is modified or augmented from the "outside" to leverage JMX.

All of the solutions featured in the presentation can be run using Mustang, which is available now.

It's important to return snapshot values in container Java Bean objects since it ensures consistency among the container's data elements. It possible that the container's attributes could become discoupled if accessed independently.

A problem that's being addressed by MXBeans is that the container class must be known in advance by the JMX client accessing a container instance. MXBeans were designed for the instrumentation of the VM itself (JSR 174).

JMX Web Services Connector is being defined by JSR 26. Allows clients of JMX agents on non-Java platforms to monitor a Java application while exploting the web platform. It supports SOAP 1.1 over HTTP. It works with non-JMX clients by publishing a WSDL at a known location. It relies on basic authentication and SSL.

An AJAX/JSR 262 demonstration was given that represents a non-Java client running with a JAX stack. It showed how an MBean agent can be accessed using XML Web Services, and the content provided by JMX is displayed and updated in a web browser using AJAX.

In Java 1.7 (?!?) Dolphin, there is a proposed feature that will allow cascading of MBeans through Master-Slave server relationships. This would allow a JMX client to access the master and have access to MBeans residing in slave servers.

Posted by Scott at 12:52 PM | Permalink

The General Session of JavaOne 2006 kicked-off with Johnathan Schwartz introducing several members from industry, including Marc Fleury from JBoss. Fleury recently had his company, that provides support services for the open-source JBoss Java EE application server, acquired by Redhat. I have an eternal grudge against Fleury because of his rude and offensive behavior at a small, birds-of-a-feather session during JavaOne 2003. His arrogance and preference for offensive language make him less of a leader, in my mind. In any case, Schwartz was thrilled to associate Sun with JBoss.

A demonstration was given on the AJAX capabilities of Java. The age-old Petstore application was re-worked to use AJAX. It featured some nice UI techniques to make the website more dynamic and visually-appealing. The website where the Petstore demo can be obtained from is here.

Posted by Scott at 12:50 PM | Permalink

At work, we ran into a problem where older releases of our product incorporate a Java Applet that's digitally-signed with a certificate about to expire in a few weeks. The role of digital-signatures is to verify the authenticity and integrity of electronic information based on the shared-trust of a certificate-authority (CA), such as Verisign or Thawte. Most CA's issue certificates that are valid for at most two years because the quality of the trust relationship between the CA and the organization seeking a certificate degrades over time. To combat this (& to sustain the CA's business model), the certificate must be renewed at regular intervals.

So, we needed to determine what behavior to anticipate from our customers when our certificate expires. I set the system clock forward on a VMware image of Windows XP and experimented with the Java Plug-in versions 1.4 and 1.5. To my surprise, the Applet functioned without any warnings when the certificate had already been imported into the plug-in keystore. And when the certificate was not in the keystore, the normal certificate acceptance dialog was presented with just an additional warning message about the expiration status of the certificate.

This puzzled me since the plug-in should honor the expiration of certificates by treating code bearing their signature as untrusted. I googled the subject and learned that the Sun JSSE stops verifying the certificate chain once it encounters a certificate it trusts. In the case where the certificate has been imported into the plug-in keystore, this occurs immediately and the CA certificates aren't consulted. Still, the expiration date of the certificate could be enforced regardless of the keystore-status. But this is not the case.

This represents a minor security vulnerability since it implies that all certificates issued to an organization can be viewed as "active". The private keys of expired certificates must be guarded in the same manner as non-expired certificates. This translates well to the old-world of corporate letterhead. Most companies are careful not to leak unused paper stock bearing the company's letterhead since it may be used to impersonate someone from the company. Similarly, the private keys for expired certificates should be destroyed or stored safely so that they may not be used under false pretenses. Failure to do so could result in the distribution of malicious software bearing an innocent organization's name, resulting in possible legal and economic damages.

I also learned that the Sun Java Plug-in 1.5 supports a time-stamp property in digital signatures that honors any code signed by a certificate at a time when the certificate was active, even if it is now expired. This makes sense for organizations looking to extend the use of their signed-code. It relies on the use of a time-stamping authority who can vouch that the signature was generated on the date/time indicated. This sounds like an interesting idea, but I think it works in opposition to the CA-model where the currency of a certificate is used as a measure of trust.

Posted by Scott at 9:36 PM | Permalink

EMC Documentum will be sending me to the annual JavaOne conference for the first day (Tuesday, May 16). While I attended all days of the conference in past years with SRA, it's still nice that EMC is sending some people. I heard that SRA isn't sending anyone from my previous contract. Anyhow, here's my schedule for Tuesday. I'm most interested in the following areas: Spring Framework, Java Management Extensions (JMX), and AJAX (a.k.a. Web 2.0). I'll be blogging my notes from sessions during the conference, so keep posted.

Posted by Scott at 11:27 AM | Permalink

"Scooter-B Software" Logo
Originally uploaded by urlgrey.

Posted by Scott at 10:25 AM | Permalink

Really Simple Syndication (RSS) has had a profound effect on my life in a fairly short period of time (about 1 year), and has probably impacted many more people in a similar way. RSS makes tracking blogs, news stories, e-mail, and podcasts easy and automated. And it's really a wonder that nobody thought it sooner.

RSS falls into the "meta-data" category - it is data about data. The information an RSS document contains varies, but there are a few constants:

a list of records, each containing:

• a date/time


• a title or subject


• a Uniform Resource Locator (URL) where the entry can be accessed via the Internet

Most people read RSS entries chronologically. They know the date/time when they last read the RSS "feed", and want to know if any new entries have been added since then. This is a very easy request to fulfill. Instead of constantly polling your inbox or your friends blogs, you can use an RSS reader to check the status of them all in a single glance.

Software can automate this task, and poll the feed at any interval you want. This isn't as easily done with traditional information sources. Consider a department store: there is a ton of meta-data sitting idle that could be tapped in ultra-valuable ways. Imagine an RSS feed for the newest additions in your favorite clothing department, or a listing of the most recent sales promotions, or a listing of the most recent transactions for the store manager. All of this information is available but is not organized and processed in a unified way. I think that RSS and similar technologies have the ability to bring all of that information to those interested in a simple, convenient medium.

Posted by Scott at 9:23 AM | Permalink

Last Sunday, I had lunch with 4 friends I haven't seen since I was attending U.C. Davis. In 2001. Five years ago(!). In a random "what-are-you-up-to" e-mail recently exchanged between Jeff and I, it came to be known that we live a mere 4-5 blocks away. What's more, my old roommate Conrad lives only a couple houses away from Jeff, so he is equally close!

So, Jeff, Conrad, and two other guys (Yang, Naoki) from our Computer Science program met up for lunch on Sunday. It was great to catch up and hear what people are doing since obtaining their Bachelors or Masters degrees. I am fascinated with the broad range of jobs open to people studying Computer Science. There are the obvious software engineering jobs; but, also the not-so-obvious jobs dealing with computer/network security, configuration management, industrial control systems, etc.

I think that undergraduate Computer Science programs do a good job of providing students with the skills to work in a variety of jobs in the field. But it is up to the students, upon graduating, to decide how they want to apply their new skills in a way that serves society best. It's much like a parent providing their child a moral foundation upon which the child can build a structure composed of experiences influenced by their moral beliefs.

A problem I've seen with computer-related jobs is that fine-grained skills quickly become obsolete. Programming languages come and go, design tools are replaced, and application frameworks are eternally subject to popularity trends. But in the end, the basics rarely change. Just as it takes commitment to stay morally-grounded, it takes commitment to stay keen on the underlying concepts of one's trade.

Posted by Scott at 9:50 AM | Permalink

Not long ago, Natalie and I were dining with her friend Jeff and his girlfriend. At one point, Jeff asked me if I have any food cravings or indulgences. I paused for a few seconds before answering, but couldn't think of a single thing I crave. He refused to believe that there is nothing I crave. But, honestly, I crave nothing. It made for an awkward conversation, since everyone else at the table was able to rattle off their biggest cravings.

I have been fortunate enough to have a high metabolism and thin physique throughout my life, though it does pose occasional problems (I need to eat at least every 3 hours). So, I eat pretty much anything I want without feeling guilt. I understand that most people don't have this luxury. And I think it is those people who crave food. Cravings can be seen as by-products of deprivation. When you deny yourself nothing, you crave nothing. I think it's a variation of the saying "absence makes the heart grow fonder."

Yesterday, Natalie posed a similar question to me: "which do you prefer, saltine crackers or wheat rounds?". Knowing that I enjoy most food equally-well, I had to respond "Which one is closer?". I go for the low-hanging fruit; or crackers, as they may be.

Posted by Scott at 2:57 PM | Permalink

Natalie's friend Evany recently released her book "The Secret Language of Sleep", which I ordered off Natalie's wishlist just earlier today. Evany's website features a questionnaire that determines the ideal sleep position for you. Mine is: the tetherball. I recall Natalie saying that she obtained the same result. So, I guess it's just meant to be for us to be together - our sleep positions are compat! I'd hate to think of the alternative...

Find your own pose!

Posted by Scott at 2:48 PM | Permalink

I've been a fan of the indie band "Built to Spill" for many years. Their super-extended guitar jams and ethereal lyrics are excellent for 'tron'ing out (programming for long periods of time). The band released their first album in about 3 years, and it's titled "You in Reverse".

I downloaded the "Going' Against Your Mind" single from iTunes a couple months ago, and consider it one of my favorite songs on the new album. As with most Built to Spill songs, it provides wide expanses between the vocals that encourage improvisational guitar-work. Other good songs include "Just a Habit" and "The Wait".

Natalie isn't much of a Built to Spill fan, but she selected "The Wait" on my iPod while we waited at a traffic light in Pleasant Hill that took nearly 5 minutes to change green since the wait was killing her. I think that Built to Spill songs are successful at making constrained circumstances bearable. Such as being stuck in a car at a traffic light for 5 minutes in 85 degree weather with the windows down. Their songs always put me at ease.

We'll be seeing Built to Spill at Slim's in San Francisco next month on one of the 4 nights they will be performing. I'm totally excited, but Natalie doesn't share my enthusiasm. Her self-diagnosed Attention Deficit Disorder (ADD) makes to difficult to endure their long-running songs (7+ minutes each). She saw them perform live once before, and said that they played "The Plan" for 25 minutes. She's lucky to have made it out alive. Hopefully that experience won't be repeated :)

Posted by Scott at 12:13 PM | Permalink

I began working on a project I set aside about 6 months ago that includes a Java Web Application programmed with the Spring Framework. I am mostly interested in getting some experience with technologies that I don't use in my 9-5 job. The new territory I'm covering (or re-visiting, actually) is web page design (yikes, I'm a engineer!) and database schema design.

I'm using the Spring Framework to create a Model-View-Controller (MVC) architecture, and have found that it ties together with back-end and presentation technologies very nicely. It took me a while to learn the lingo of Java Servlet development since I haven't ventured beyond XML Web Services and client-server development in a couple of years.

Once I had the routine down, cranking out code and GUIs was progressing at a lightning-pace! I could easily get the functionality of the project done in a weekend. An since the Java Server Pages (JSPs) are using the model data in a super-decoupled way, changing the look-and-feel of the web site should be really easy. I would hate to design a large interactive web-site with anything besides Spring.

Posted by Scott at 6:48 PM | Permalink

A customer issue I am dealing with at work involves the use of HTTP 1.1 chunked transfer-encoding on the BEA Weblogic 8.1 application server (SP3, in this case). Chunked transfers offer a very efficient method of transferring large amounts of data since they allow the payload to be broken up into manageable chunks of data. The alternative is to transfer the entire payload in a single message (expensive since it needs to be buffered in memory), or programmatically divide the payload into pieces for sequential transmission (difficult, requires a non-standard protocol between receiver and sender).

So, HTTP 1.1. chunked encoding is being used by our product to transfer large files between the client and server. It should work fine, except that it relies on the application server/web server to have implemented the HTTP 1.1 protocol correctly. I've come to learn that BEA's Weblogic 8.1 application server has the poorest implementation, by far.

The most aggregious offense is that client requests using a fixed content-length (alternative to chunked transfer-encodings) will occasionally receive a response that uses chunked transfer-encoding. This would be like asking someone to call you back on the phone, but instead they write you a letter. Fortunately, our client doesn't make much of a distinction between the encoding used; rather, it just cares that a response is provided.

Additionally, there is a bug in Weblogic 8.1 (S-31186) where use of chunked transfers in a cluster will result in buffering of the HTTP response. Buffering of communications for an undetermined amount of time doesn't work for real-time applications like ours. It appears that disabling the use of chunked transfers altogether in the server's config.xml might solve the problem, but that's a horrible compromise to make.

However, if a system sits between the client and application server, it's possible that the system would be confused by the mismatch in encodings. I've noticed that when an Apache HTTP server is configured as a reverse-proxy (a common setup that limits web traffic to a DMZ) a chunked response can be buffered by the HTTP server for as long as 9 minutes. This is long enough for the client to time-out and disconnect under the assumption that the server is unreachable. This has resulted in more than a few headaches as I've tried to remedy the situation.

So, I have one point to make: protocols and standards exist to make communication easier. Deviation from protocols (i.e. slang) results in conversations that can be difficult to understand. Companies such as BEA wouldn't write a press-release composed in slang. So, why would they release their core product with a half-ass implementation of a communication protocol? People are building products and basing their success on the quality of products like BEA Weblogic. How about a little professionalism? Please?

Posted by Scott at 4:54 PM | Permalink | Comments (1)