Welcome to Rotowatch

How do you do localization in a language which doesn’t allow you to import files?

The best possible way to do this would probably be to not keep any strings within your javascript files. By pushing all strings to the JSP/CGI layer, you allow a higher level language with internationalization support to take care of localization for you. However, that isn’t always possible and I’m going to talk about what to do in situations where you have to do this.

IBM has a nice page on internationalization and JavaScript that describes their suggestion : multiple versions of a file for each language. For the project I’ve been working on, I found this the best way to handle things. What I ended up doing was tokenizing all of the strings so that:

alert("Hello world");

became

alert ("@hello.message@");

Then, using ant and properties files, I was able to do token replacement to replace all tokens with corresponding key/value pairs from a properties file resource bundle. This allowed me to keep all of my internationalized strings in .properties files just like the rest of the application.

<loadfile srcfile="${src.file}" property="${src.file.replaced}">
<filterchain>
<filterreader classname="org.apache.tools.ant.filters.ReplaceTokens">
<param type="propertiesfile" value="sample.properties"/>
</filterreader>
</filterchain>
</loadfile>
<filterchain>

With multiple languages, the above probably isn’t optimal - I used ant macrodefs to define a macro for doing the replacement, and then just executed the macro with the properties file name and the locale for each language.

What is required here is a patch to ant that is going into Ant 1.7. Ant already does property/key replacement, so the patch was pretty easy. All of this is being done at build time, so there’s no performance hit, and only one version of the file (the one with the tokenized strings) needs to be maintained.

Another strategy that I thought of was to do an xmlhttp request for each string. I decided not to use this approach because it seemed like it was expensive - an extra request per page at least.

One of the first things I do at work is check out my newest bugs, and today my bug queue was filled with bugs regarding our upload control, which happens to use ActiveX.    I’m not a fan of using ActiveX for uploads - I hope to change to a hybrid use of single file HTTP upload and multi-file applet upload, but for now we do all of our multi-file uploads by using an Active X control.

The main problem I had with the patch was not the extra interaction required, but that enabling the ActiveX object with a click changes its position.     An HTML table that appears above the DIV containing the ActiveX object suddenly disappeared from the page once the ActiveX object was enabled by a user click.     We had previously thought that this update was not going to effect us since we could live with users being required to click on the ActiveX object before using it - but the repositioning of the object that we saw required a fix.

This article from devx talks about the lawsuit and is entitled “Users lose”.   I don’t think that’s entirely accurate - users don’t really lose in this, developers do.    The suggestion that Microsoft makes is that if you want to preserve current behavior, you simply use javascript to display the OBJECT, APPLET, or EMBED tag.     You can do this by using document.write(”") to print out the tag, or use the DOM to add an OBJECT/EMBED/APPLET element, but this extra scripting step is required so that the user can immediately interact with whatever multimedia element is being displayed.

From a technical standpoint, this is kind of ridiculous.    There’s no reason for these tags to work with the use of javascript but require user input otherwise.    Javascript simply provides an interaction which can provide a path around the patent.   

Who is to blame for this?    Are Software Patents to blame for providing protection for something which seems so obvious and generic in applicability as plugins?    Is Microsoft to blame for not respecting and licensing Eolas’s patent?    Is Eolas to blame for patenting this process?

I’m currently tracking down database connection leaks, which is always fun.     In the new version of our product, we’re using JBoss’ local-tx-datasource.    In our last version, we were using a javax.sql.DataSource declared as a resource within a <context> (see here).    Does anyone know how to get JBoss’ local-tx-datasource to log abandoned connections?

I’m currently doing this by populating an exception in the initializer of our Database delegate class, setting it to null on a database close, and then printing it if it is not null on finalize.     I’d rather use the container to do this sort of thing though.

During the last week, I’ve been playing around with Maven and Ivy, trying to figure out which one would be better for moving our dependencies out of CVS.      For a small project or a prototype, I’m not really sure that a dependency manager is necessary.     It’s probably easier to just check 3 or 4 jars into CVS and move on.

For our main CVS module though, we have upwards of 80 jars in the lib directory.   11 of these are xdoclet jars, 11 are Apache commons jars, and 9 are different versions of JOSSO jars that are used depending upon what version of Tomcat or JBoss is being used.     When dealing with this many JARs, it begins to make sense to have something to keep track of these other than CVS.    Since we aren’t strict with our compile classpath (we just build off everything inside the lib directory), I think there could be potential situations where we might build successfully against an obsoleted API, but we break in runtime because we only deploy a specific set of JARs.

Maven has taken some getting used to.    I’ve started using Maven 2.0.    The strengths seem to be the project archetypes, which gets you going quickly with a specific project structure.    I’m not sure that I agree with all of the project structure decisions that were made with Maven, such as the fact that tests are split out into a separate source hierarchy as the classes they test.

I also feel like I’m giving up a great deal of freedom in how I lay out my project in using the Maven 2.0 archetype to generate my project structure.     For example, when I generated Hibernate hbm.xml mapping files this weekend along with classes, I started by putting them in the main/java tree until realizing that Maven would not copy the hbm.xml files unless they were in main/resources.    Makes sense, but seems like sort of a waste to have three separate package hierarchies in java, resources, and tests.

The strengths of Maven are it’s dependency manager though.    It is easy to find jars