Puakma: Under the hood

I'm Brendon Upson, jack-of-all-trades, master of one or two. I'm talking about life running a small ISV tackling business issues and leaping technology hurdles in a single bound.

webWise Network Consultants is based in Sydney, Australia and develops the groundbreaking Tornado Server technology.

i18n: International alphabet soup

Filed under: by Brendon Upson on 2005-04-27

What's so special about ø and è¿ Absolutely nothing until you try to work with them. A large speed hump from a few weeks back was internationalization, or i18n to its friends. Why i18n? because there are 18 characters between the i and n. But I digress.

For reasons quite unknown to us, Puakma is very popular in Europe. With our other products in the past, the US was clear winner in terms of customers. i18n was something we skimmed over as Australia has no "special" characters, ASCII text works absolutely fine for us and really for most of the world the first 127 characters are the same. It's only when you go above 127 into the special zone things get very confusing.

For the most part Java does a brilliant job of keeping everything in its correct character set. Data is always stored as UNICODE inside strings. But as we manipulate that data sometimes it needs to be put into byte arrays or byte streams, like when we send data to the client, receive data from the client or serialize some object to a disk file (like exporting a web application to a .pmx file). Stepping from the safety of UNICODE to the wild frontier of bytes is very, very dangerous. Streams must be read with one character set, manipulated in UNICODE and wirtten in a another character set. One false move and your ø becomes a ?.

Western languages are now handled correctly but we have no facilities for testing more extreme character sets, like chinese, hebrew, arabic etc. Like everything, I know this will come up in the future and we'll cross that bridge when we get there. For now we have probably >85% of our potential customer base covered, and that will do while we round out the IDE.

Dear IDE, my how there's so much riding on you.....

Gettin' down and dirty with ClassLoaders

Filed under: by Brendon Upson on 2005-04-27

Last week we had an issue reported by a Business Partner that Puakma Enterprise Server would not allow objects stored in memory on a user's session to be accessed. ClassCastExceptions were being generated. This means Java was unable to convert object A into object B. We had tested the session storage mechanism a number of times, and hell, we were even using the feature in production at a customer's site. Just goes to show, the more people get your product, the more they use it in ways you never thought about.

The issue in this case was with Puakma's ActionClassLoader. This class is responsible for retrieving class files from the relational database, and any associated libraries that are defined to go with them. Our problem it seems stemmed from the fact that an ActionClassLoader was created and discarded with each web request. We designed it this way for very good reasons:

  • Design elements can be updated/replaced in real time and a new ActionClassLoader picks up the new design.
  • The name of a design element may be different from it's actual class name. eg The name in the design collection may be "ResetCustomerCodes" while its actual Java class name is "foo" (hey, it's an example, we definitely don't recommend this naming schema!)
  • So the issue was that a custom class "MySystem" existed in the libraries area and an instance of this was stored on a user's session. Trouble is, a reference to the classloader that created the object is also tagged to the object. After the initial load, the classloader is lost and subsequent casts fail because the classloader is no longer available.

    We spent the last few days building a new classloader mechanism, now called "SharedActionClassLoader" in which a classloader is created for each application (for each .pma). Repeated requests to the same application yield the same classloader. So far so good.