Matthias Ernst's Weblog

CLR versions

I just downloaded Avalon & Indigo RC. Avalon would not install - I figure it's because of the Avalon CTP that's still lying around. Trying to UNINSTALL Avalon CTP, I get the following neat error message:

I guess I haven't figured out Microsoft's versioning story yet. I have a more recent 2.0 beta 2. Why can't it just use that one? What do I do? I will _NOT_ deinstall beta 2, install 204xxx in order to deinstall Avalon CTP. .NET's beta track feels much more painful than Java to me. C# Express and SQL Server Express had incompatible CLR requirements as well. I understand that, but why can't I simply install both?

I would appreciate some tips on this.

Class.newInstance and Pawlovian dogs

I'm a Pawlovian dog. My bell is Class#newInstance. Whenever I see a framework that allows you to configure extensions via classname and does Class.forName().newInstance(), I think "you should integrate that with spring".

Here's how I did it for ULC. ULC is Canoo's "Universal Lightweight Client" - a ui framework that runs a swing ui engine on the client but all the ui and application logic on the server. ULC comes as a servlet accepts the application class as an init-parameter. For every new UI session, it will instantiate it and call start() - then you're left alone. Now you can go and find friends - typically via ServletContext. Since I prefer dependency injection over service locators I want Spring to instantiate my application class WITH dependencies.

Unsurprisingly, it's very easy. I wrapped the ULC servlet in a controller which gives it a bootstrap application class name. This bootstrap application grabs the current application context and the application bean name from the request, instantiates the application bean (MUST be prototype bean definition), and delegate all ULC lifecycle calls to it. Alternatively, my code can instantiate a whole child context per UI session if you have more beans you want to set up per session. For example:

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
  <bean id="listModel" class="com.ulcjava.base.application.DefaultListModel"/>

  <bean id="eventDispatcher" class="org.mernst.ulcjava.EventDispatcher">
    <property name="eventQueue" ref="eventQueue"/>
    <property name="delay" value="5000"/>
    <property name="handlers">
      <map>
	<entry key="org.mernst.ulcjava.ListUpdateEvent">
	  <bean class="org.mernst.ulcjava.ListUpdateHandler">
	    <property name="model" ref="listModel"/>
	  </bean>
	</entry>
      </map>
    </property>
  </bean>

  <bean class="org.mernst.ulcjava.Viewer">
    <property name="listModel" ref="listModel"/>
  </bean>
</beans>

Net result: ULC applications can be easily set-up in Spring - no more service lookup necessary. The code should appear soon on http://ulc-community.canoo.com/.

Spring starts to be the all-integrating technology - lately we built an integration to host the WASP container and export Spring-managed web service implementations.

Specs and Implementations

Something's wrong with software specifications. Almost every JSR defines an API in form of Java interfaces. Can I download these interfaces in a jar file? No, the API typically comes in form of JavaDoc that every implementation has to reverse-engineer into Java code and a "reference implementation" that contains _a_ version of the interfaces. As it stands, there are no official servlet-api jars to write software against. There's the Tomcat servlet apis and there's a lot of others. Have you found yourself with two, say, jmx.jar in your app? Nominally the same version, yet different size? Can I drop one, you ask yourself? Will something break?

Even worse are specifications that spell out algorithms over pages in pseudo-formal notation. Bullet points instead of loops. Ambiguous, natural language, open for interpretation. Have a look at the JSF specification:

Examine the FacesContext instance for the current request. If it already contains a UIViewRoot:

• Set the locale on this UIViewRoot to the value returned by the getRequestLocale() method on the ExternalContext for this request.
• For each component in the component tree, determine if a ValueExpression for “binding” is present. If so, call the setValue() method on this ValueExpression, passing the component instance on which it was found.
• Take no further action during this phase, and return.

This goes on for pages. The whole request cycle spelt out in Jenglish. What the heck? Why don't they invest all the time they've debated about the words in a better base implementation with useful extension points? Instead a verification kit is produced to ensure a vendor did a correct job translating the english back into code. When I look at many bugs I encounter in standards implementations I question the quality of these TCKs.

Well, enough now, I actually wanted to read the JSF spec ...