Tag Archives: XML

Setting up HSQL and Hibernate for Unit tests

I know, this sounds a bit too specific to really bother you but since it’s a nice thing to do, and I use it really often during development I thought I’d share it with you.

The scenario

You are developing an application where you heavily rely on a database and want it to be tested during your unit tests. In my case I have an application that uses Hibernate that is connected to an Oracle database for it’s data persistence. Now I want to write some Unit Tests, using JUnit, to see wether all works fine and my objects get serialized and restored correctly. Usually I would have to set up another database with my structure and then test it on that, but JUnit explicitly discourages this as it requires you to setup the same environment on all machines that will test the code.

The solution

The solution is HSQLDB. HSQLDB is the leading SQL relational database engine written in Java. It has a JDBC driver and supports a rich subset of ANSI-92 SQL (BNF tree format) plus SQL 99 and 2003 enhancements. Along many other features it can also run in a memory resident mode, that will keep all of its data in memory and it is lost after the execution finishes. At first sight this may seem a useless feature, but think about what exactly you need when running unit tests: a simple to set up database, that is freshly instantiated with every run. And HSQL is easy to set up, in fact so easy that a single line makes all the difference.
So what once was my hibernate configuration file:
 
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC 
    "-//Hibernate/Hibernate Configuration DTD 3.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
    <session-factory>
        <property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
        <property name="connection.url">jdbc:oracle:thin:@hostname:1526:orcl</property>
        <property name="connection.username">username</property>
        <property name="connection.password">password</property>
        <property name="connection.pool_size">10</property>
        <property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
        <property name="current_session_context_class">thread</property>
        <property name="cache.provider_class">org.hibernate.cache.SwarmCacheProvider</property>
        <property name="show_sql">true</property>
        <mapping resource="events/Event.hbm.xml">
    </mapping>
</session-factory>
</hibernate-configuration>
Now becomes this:
 
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC 
    "-//Hibernate/Hibernate Configuration DTD 3.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
 
<hibernate-configuration>
    <session-factory>
        <!-- Database connection settings -->
        <property name="connection.driver_class">org.hsqldb.jdbcDriver</property>
        <property name="connection.url">jdbc:hsqldb:mem:somename</property>
        <property name="connection.username">sa</property>
        <property name="connection.password"></property>
        <property name="connection.pool_size">1</property>
 
        <!-- SQL dialect -->
        <property name="dialect">org.hibernate.dialect.HSQLDialect</property>
 
        <!-- Enable Hibernate's automatic session context management -->
        <property name="current_session_context_class">thread</property>
 
        <!-- Disable the second-level cache  -->
        <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
 
        <!-- Echo all executed SQL to stdout -->
        <property name="show_sql">true</property>
 
        <!-- Drop and re-create the database schema on startup -->
        <property name="hbm2ddl.auto">create</property>
 
        <mapping resource="events/Event.hbm.xml">
    </mapping>
</session-factory>
</hibernate-configuration>
Special attention is needed with the connection.url property and the hbm2ddl.auto property which tell hibernate to use a memory resident HSQL Database and to create the database structure at startup, which is exactly what we need for our Unit-Tests. Now for this to run you only need to include the HSQLDB Jar in your classpath and everything will run as it used to, only that it is much easier to test in a new environment, thus making it perfect for continouuous integration.
To sum it all up here are the steps to migrate to HSQL for testing:
  1. Add HSQLDB to your classpath
  2. Set the driverclass to org.hsqldb.jdbcDriver
  3. Set the dialect to org.hibernate.dialect.HSQLDialect
  4. Set the database URL to jdbc:hsqldb:mem:somename
  5. Run your tests :)




powered by performancing firefox

Did you like this? Share it:

Quality of Ajax in modern development

Just ran ran over a nice post on ITtoolbox and I must say that Dan Morrill is quite right in saying:

AJAX is only as good as the examples that the developers have, while it is great to have properly formatted XML and HTML as the output, the basics of information security still have to apply to the process. AJAX is a really great way of embedding dynamic data into a web page without having to go through the entire page load process that we otherwise work with on a Web Server.

But AJAX is not an excuse for following very poor coding practices that have been pretty well deprecated over the last couple of years since cross site scripting and SQL injection have become pretty familiar terms to many in the IT industry.

Ajax shouldn’t be used for the sake of doing Ajax. Ajax does not make poorly designed and useless pages/applications good. Ajax is not the answer to everything. Sorry guys, Ajax won’t make you rich without any effort…
Did you like this? Share it:

XML11: An Abstract Windowing Protocol

Just today I stumbled across a nice presentation about XML11, an Ajax Toolkit that bridges Java AWT applications right to the Web using modern Ajax-technologies:
The goal of XML11 is to help programmers write AJAX-applications without requiring any JavaScript knowledge. AJAX (Asynchronous JavaScript and XML) has become very popular for building web applications. AJAX basically proposes to move part of the application to the browser without requiring a JRE-plugin. In order to do so the application needs to be written in JavaScript since JavaScript is the lowest common denominator across different web browsers in terms of prerequisites. Writing portable JavaScript is a daunting and tedious task. XML11 allows you to write your application in Java (not JavaScript!). XML11 then translates your Java application to JavaScript so that it can run inside any browser. Just like a C++-compiler shields the programmer from the assembly language, XML11 shields the web-developer from the intrinsic complexities of writing cross-browser portable JavaScript code. As a consequence, a web-developer never has to write or even look at one line of JavaScript code. (source)
Personally I think the approach to the VM simulation using XMLVM a bit an overkill and it might lead to a lot of overhead it’s actually not that bad, due to moore’s law we probably should bother too much about it ^^
Just take a look at the presentation and you will fall in love with it :)
Did you like this? Share it:

Is combined server and client side validation possible?

When working with Ajax sooner or later you will run into the need to validate data the user has entered. The Ajax approach to validation would be client side validation (using a JavaScript on the browser) which gives the user a direct feedback for the values entered. While non-Web 2.0 applications rely mostly on server side validation, requiring a full round trip to the server and back before the user actually sees the validation result. While server side validation is slower it has some advantages over client side validation:
  • It can’t be fooled: while JavaScript can be turned off, or manipulated injecting scripts.
  • The server can perform security test, such as checking a password, without making the check vulnerable to viewers (remember: never check on the client side if the password is correct ^^)
  • Formatting errors will be recognized.
But Web 2.0 developers just love those fancy instant validations they can do with JavaScript so why not combine them? There are basically 3 different ways to validate data:
  • Client side (JavaScript): the easiest way to validate a field is to attach a callback function to a field that will then check if the value is valid.
  • Server Side (Ajax): for some operations we want on the fly validation but have to do a roundtrip to the server, for example to see if a username is still available.
  • Server Side (Submit): the classic way of doing things. User submits Form, Server validates and performs actions or throws out a bunch of validation errors.
All three of these techniques have their advantages and disadvantages, while the Client side (JavaScript) is the fastest it is neither secure as it can be turned off, nor applicable to every possible situation (see the Username example). The Server Side (Ajax) method is the nicest as it virtually allows any validation possible but it too can be turned off and it involves a full round trip making it slow and requires some extra data handling. The Server Side (Submit) method is the most secure method but it is the slowest and does not give immediate feedback on a user action. Nevertheless the server side validation (submit) should never be omitted since the others can be turned off, and we don’t want the user to add bogus data, do we?

So what’s our best option? The logic step would be combine them together so we do react on user actions immediately giving him some feedback and we are secure that the data is validated at least once (on the server) before we operate on it.
The main problem now is that we would have to write most of the validation criterias twice (once for the server side and once for the client side). What we need is some sort of meta-model for the form in which we describe the datatypes and validation tests we want to execute on them and then generate the Form on the fly out of this model. This idea isn’t actually new (and it would be wrong to give me the credits for it :-) ), I stumbled over it when starting to work on a Cocoon project. At first sight the Framework looks a bit overblown but once you get started it is really easy to understand.
Basically you describe the Form-Fields in an XML file defining fieldtype and name, and, what is interesting for us right now, add some validation functions. This model will then be translated into the Form once it is requested. The validation functions will be executed both on the server side and the client side, thus eliminating the need for writing them twice.
The same could be archieved with any other scripting language, and I’m looking forward to see other frameworks going in this direction, it really makes coding a pleasure.


Technorati Tags: , , , ,
Did you like this? Share it:

Why Ajax is conceptually better

Ajax has been around for quite some time now (it is a bit more than a year ago that Jesse James Garret coined the term) and it has quite some lovers, and just as many haters. First of all let’s distinguish between two different things that are often confused when we talk about Ajax. What many think to be Ajax are relly two independant things:
  • Asynchronous Communication: allows fetching and sending data asynchronously, in the background.
  • DOM-Manipulation: which allows all those fancy flash-like effects on webpages, such as zooming images, floating windows, but also really basic stuff, like swapping text in boxes.
If we want to split hairs there is a third thing that makes up those Web 2.0 applications: a logic layer, which takes care of the execution of the applicationMany of the haters argue that by using these techniques the programmers make nice applications but make things more difficult, adding complexity to the client, which before Web 2.0 was a viewer, creating portability issues and last but not least excluding all those visitors that do not use a supported browser. But let’s go a bit deeper into the things involved, when building a web service. First of all we’re able to identify three different parts:
  1. The Server side application: this may be as complex as you want but for our purpose we’ll just assume that it gets some input from the user, processes it, updates its internal state and returns some data to the user.
  2. The data: the input and output data of our service.
  3. The User Interface: this is where the user gets to see the data in all its beauty (or uglyness as it often happens).
Now in the “old” way of doing things, let’s just call it Web1, parts 2 and 3 where clustered together. With the current development in the Web 2.0 we tend to divide the layers 2 and 3 again by completely dividing the layout from the data. The idea is to download a relatively small engine that takes care of what happens on the page, and fetches asynchronously the data it needs from the server, often using data encapsulation methods such as JSON or XML. This is actually one step forward, but in the meantime a return to the roots of the Web: we now serve “pure data” or content, without all the formatting clutter that scrambled our data back in Web 1. The reduction of redundancy is a nice side effect, not having to download the layout on every refresh. The fact that we serve pure data using standard formats and standard protocols allows us to create non-human interaction between a web service and a client, the data is available for further elaboration and is independant of its actual representation in the User Interface. And here we are, welcome to the Semantic Web.
Humans are capable of using the Web to, say, find the Swedish word for “car”, renew a library book, or find the cheapest DVD and buy it. But if you asked a computer to do the same thing, it wouldn’t know where to start. That is because web pages are designed to be read by people, not machines. The Semantic Web is a project aimed to make web pages understandable by computers, so that they can search websites and perform actions in a standardized way. The potential benefits are that computers can harness the enormous network of information and services on the Web. Your computer could, for example, automatically find the nearest manicurist to where you live and book an appointment for you that fits in with your schedule. A lot of the things that could be done with the Semantic Web could also be done without it, and indeed already are done in some cases. But the Semantic Web provides a standard which makes such services far easier to implement. [From Wikipedia]
The potential of the Semantic Web is just unimaginably huge, to say it with The Hitchhikers Guide to the Galaxy’s words: it’s big. You just won’t believe how vastly hugely mindboggingly big it is. And there are already some examples: Remarkably we can find almost every big player of the Web 2.0 movement in the list, because it many services already rely for their internal workings on XML or JSON, so it becomes really easy to access them, even without the original “Web Frontend”.
Did you like this? Share it: