Like all good developers, I’m lazy. I follow the DRY principle.  On my current project, that means using our Oracle schema as the design of record, and then using iBATOR to generate our DAOs and transfer objects.  It also means extracting documentation out of Oracle.

One of my co-workers, Phil, found a very nice tool called Oradoclet that grabs the metadata and code from an Oracle database and outputs it in a Javadoc like form (see the example).   Unfortunately, it’s limited to Oracle, and apparently hasn’t been maintained in a few years.

It works quite nicely for our purposes now, and Phil and I are talking about reviving the project to expand it to other databases.  Our ultimate goal (a long way off) is a project-wide meta-data management system, that links the Java elements to the database objects (and ideally to requirements, UI screens, etc.)  We’ll see how that turns out.

After going into a demo blind last week (bad idea!) and having our application fail on the demo laptop (big surprise!), I had to figure out why our application completely refused to work using Internet Explorer 6.  Turns out that IE 6 is totally flummoxed by the HTML <button> tag.  If you have more than one a page, IE submits all the buttons - so in our case, the last one was winning.

I had forced Apache Beehive to display all the buttons using the <button> tag so I could take advantage of setting a global style.  Obviously that was now out of the question.  I had to switch back to using <input type=”button”> tags (by removing the Beehive attibute renderAsButton=”true”) and apply a style to each of them.  Crisis averted, but only after an embarassing incident in front of the customer.

P.S. The problem is resolved in IE7 - where we’d been doing all of our IE testing.

In one of my current projects, my application has some pretty strict security requirements.  It’s designed so that only a small piece of the functionality is available to external users, while the full application can only be accessed by internal and partner users.  To ensure that the line isn’t breached, we’ve set up two parallel environments - the private side runs on the same servers as the rest of the internal applications with the public side isolated from the more secure internal applications.  This isn’t really anything that out of the ordinary.

Obviously we’ve got authentication and authorization procedures on the public side to ensure that users only see only what they’re allowed to see.  But is there a way to be even safer?  What if our public application included only the functionality that the public can see?

That’s exactly what we’ve done.  Our build script, which I’ll cover in more detail in a future post, allows us to declare Java packages to exclude from the public application package.  In the build.xml for each project, we optionally include an Ant property called “exclude.public” that contains a comma separated list of packages to exclude.

<property name="public.exclude" value="com/mycompany/myapp/packagea/**,
              com/mycompany/myapp/packageb/**,
              com/mycompany/myapp/packagec/**"/>

We’re using the Ant-contrib library to get real conditional logic within our Ant scripts, to make it easier to provide a default value for our properties in case we’d like to publish the full application.

    <target name="public-only">
        <if>
            <isset property="exclude.private"></isset>
            <then>
                <property name="excluded.files" value="${public.exclude}"/>
                <property name="dist.subdir" value="public/"/>
            </then>
            <else>
                <property name="excluded.files" value=""/>
                <property name="dist.subdir" value=""/>
            </else>
        </if>
    </target>

If we indicate we only want to build the public application, the public.exclude property becomes the value for the “excludes” attribute of the javac task - completely removing the code from the public application.

<javac srcdir="${src.dir}" destdir="${classes.dir}"
        classpathref="lib.path.id" debug="true"
        excludes="${excluded.files}"></javac>

Since the final package doesn’t even contain the dangerous code, we’ve made it impossible to execute even if all our other security fails us (unless of course we deploy the wrong package to the server).