Nov 282005
 

I’m doing it again! I’m writing another XML object generator for savant. Why on earth would I do that most will say?

1. Others like digester, JAXB 1.0, jibx, just make life difficult because they don’t handle multiple errors within a document. At the first sign of an error, they bail. Some Savant configuration files are XML and this is one of my greatest annoyances with other tools like ant. What I want is the ability to handle as much of the document as possible and look for as many errors as possible without bailing.

2. I know JAXB 2.0 doesn’t solve #1 but it is pretty freakin’ slick. However, I’m playing nice and using only JDK 1.4 (probably even 1.3) libraries and constructs. Sucks. I could ship the JRE with Savant and just use 1.5, but some companies have crazy policies about new JDK versions. They probably wouldn’t even know, but why cut out all those users just for ease of coding. Here’s a note to the world, please upgrade to 1.5! Do it now! It makes coding so much better and faster.

So, in the end I now hate XML even more than I did before and I’m going to write this stupid XML unmarshaller because that’s what needs to be done to appease my craving for good user experience. C’est la vie.

Nov 112005
 

The next version of Savant is going to focus heavily on the stand-alone runtime and support for dialects and plugins. Supporting all that is largely handled by using a simple executor framework I wrote around Java 1.4 and lower’s Runtime.exec method. A few things to keep in mind when using this:

  1. Always read from the streams prior to calling waitFor. Otherwise you could end up waiting forever on Windows and other OS platforms whose I/O buffers can’t store enough from standard out and standard error to ensure the program has finished. These platforms will pause the execution of whatever is running until something reads the buffered content from standard out and standard error. I would imagine all platforms suffer from this, but some platforms have larger buffers than others. Needless to say, always read from the streams first.
  2. Always read from standard error first. I ran across a bug where some OS platforms will always open standard out, but never close it. What this means is that if you read from standard out first and the process only writes to standard error, you’ll hang forever waiting to read. If you read from standard error first, you’ll always be okay on these platforms because the OS seems to shutdown standard error. I think however, that the best way to handle all cases is to check both standard error and standard out for readiness and only read from them if they have something to offer. The downside I could see here is that error isn’t ready, but eventually will be.
Nov 032005
 

Pontarelli.com was hacked. Yep. It sucked. I lost a lot. I have to restore my blog from a backup. But on the up side, the new version of WordPress is pretty freakin’ cool. So, for now all I’ve got to say is:

HACKERS SUCK

Nov 012005
 

I received a question about NIO and SSL via email today. Here is that message and my reply:

Hello Brian,

That was an excellent article.
http://devnet.developerpipeline.com/documents/s=9851/q=1/ddj0509c/


I was wondering if you came across the challenge of handling ssl sockets using channels and selectors in nio.

If yes, Did you solve it and if yes how?

Yeah, JDK 1.4 does not have support for SSL with NIO and I spent a while trying to determine if it was possible to get working. Turns out it is not possible (as far as I could tell) because of the handshake required for SSL/TLS during socket creation and connection. Using JDK 1.5, NIO has full support for SSL/TLS. You’ll have to upgrade to JDK 1.5 if you need to use SSL/TLS.

However, if you are unable to upgrade to JDK 1.5, there are other solutions available to you. You can use apache as an SSL filter that can accept inbound SSL connections as well as handle outbound SSL connections while allowing internal traffic to be unsecure regardless of direction. Another solution is stunnel can be used to provide the SSL security for either direction. Both of these solutions require configuration and management outside of Java, but will work for situations where updating to JDK 1.5 is not an option.