Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
In this sidebar to "XML data interchange in Java ME applications," author Mario La Menza introduces MockMe, a free tool for generating XML-based mock objects so you can test the presentation layer of your Java mobile applications without waiting for server-side data.
MockMe is a simple tool that allows you to test your Java mobile application's client code without waiting for the service layer to become available. In complex applications this means not having to wait for data to become available for processing.
MockMe is essentially a configurable servlet based on properties files, which searches for XML files from a local directory according to a parameter passed in with a data access request. It then emulates the future server to facilitate testing. Once you have defined the XML and configured MockMe, both parts can work in parallel.
In the next sections I'll quickly get you started with MockMe, first with setup instructions and then with tips for using it in your Java mobile application development.
Because MockMe is a WAR you only need to place it in the deploy directory of your server (in Tomcat this would be /webapps). Figure 1 shows a Tomcat deploy directory after the MockMe.war has been deployed.
Within the MockMe directory, you will see the following:
XML files that you want the server to return are stored in the XML directory. You will edit these files according to your needs and store them for the tool to return later, according to the operation code it receives.
The properties, config, and operations files are essential for configuring MockMe. The association between operation code and XML files takes place in the operations file.
The general configuration parameters of the tool are found in config.properties.
The operator parameter specifies the name of the operation parameter that will be passed in the petition URL. A petition for this configuration would be of the form:
http://localhost:8080/MockMe/mock?codoper=31
If you want to use the oper operator instead of the codoper, go to config.properties and replace the first line with
operator = oper
The second parameter refers to the way you want the results to be returned if more than one XML file is used for one operation code (see Figure 4). If you have the following:
random = yes
it means that the server must select the XML files at random. In the case of code 31, there are two different files, which means that it could return either of them. If instead you have
Random = no
it would only return the first from left to right for a given operation. (xml31-1 in the case of Figure 4).
The third parameter refers to the possibility of the tool logging the petitions received. This log will be recorded in the
log files (localhost.DATE.log) that are in the log directory.