mbaierl.com Blog

iBatis for Java is a good way of abstracting away the SQL statements from the business logic; it relies on XML files which contain all SQL statements and it is pretty simple to access a database. Because accessing DB2 from Java is pretty new for me I had some troubles finding a sample to setup a “insert” statement which returns the last inserted ID.
With PHP I’d use my_insert_id(), but how does it work with Java and DB2? Unfortunately all samples I could find where either based on Oracle or on the Microsoft SQL Server…. no luck.

So here is the XML required for an INSERT statement with iBatis on DB2:

<insert id=”insertTABLE” parameterclass=”TABLE”>
INSERT INTO TABLE
(…)
VALUES
(#…#)
<selectkey resultclass=”int” keyproperty=”id”>
SELECT IDENTITY_VAL_LOCAL() as ID FROM SYSIBM.SYSDUMMY1
</selectkey>
</insert>

After that the insert statement can be used like follows:

TABLE_BEAN table_bean = new table_bean();
table_bean.setXXX(…);
mySqlMapClient.insert(“insertTABLE”, table_bean);
// now table_bean.getId() returns the correct id

From now on iBatis works like a charm and the object value is automatically updated… nice!

Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?

Well, I could not agree more. Most students and new-hires do not know to work in a team for longer than a night (the last night before the deadline). And unfortunately a single, long night with energy drinks does not require source control or anything else that is required in real-world code in a real-world team…

Read the full article on JoelOnSoftware.

Unit-tests are what saves a developers ass – and each app should have them, if it makes sense. So it depends

But for the project I’m working on right now it made sense, the perfect subject for unit testing. Or do you remember almost 100 different cases and conditions which might break if you change code? In my case I rewrote about 30% of the servlet code to be better structured and being capable of implementing a new requirement. Large parts where Spaghetti code without class inheritance or good usage of objects… subject to be thrown away or rewritten.
After trying the code for the first time after the rewrite the simple, LWP based unit tests immediately showed me where I had to “tweak” the code – and now that they again show a green PASSED I’m confident that it really works in production as well.

That’s how it should be – being confident that changes did not break any other part of the code.
Unit tests are way cool!

While the follow up article of “Must-have tools for HTML, JavaScript and AJAX development and debugging” (which has also been translated to Chinese, Japanese and Korean) is not written yet I want to share a useful trick that helps debugging live Web applications by injecting custom files into them.

The problem is how to test a new version of a JavaScript library on a production system without even touching the system itself in any way. Testing with local copies of the HTML pages work fine for a few files but does not scale very well, and staging systems might not be properly configured or really tell you if something works on the production system (bugs always just happen in production, right?).
Another problem with debugging JavaScript on production system is that the files might be compressed, which makes debugging in Firebug almost impossible – variable names are shortenend and line numbers don’t make sense any more – would be great to have the uncompressed version instead…

The solution is using a local proxy and replacing certain requests with local files. That way custom files can be injected based on regular expressions and tests can be performed on the production site or even on sites without access to the system itself.
While Fiddler works great on Windows and Charles Proxy does the same on OSX I want to present the poor man’s solution which makes use of any local Apache installation (i.e. MAMP).

The required changes in the httpd.conf are:

# Enable proxy requests
ProxyRequests On
ProxyVia On
<Proxy *>
# Secure the proxy to allow localhost requests only
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1

# replace some files with local copies
RewriteEngine On
RewriteRule myfile.js http://localhost:8888/test/myfile.source.js [P]

# Disable caching
ExpiresActive On
ExpiresDefault “now”
</Proxy>

Lets go through the changes line by line:
The first two lines enable the Apache Proxy support (ProxyRequests On); the <Proxy *> block then configures the proxy further. As stated in the documentation multiple times it is a good thing to secure the server, that’s why only access from localhost is permitted. The important part are now the RewriteRules – they proxy certain requests to the local server instead of the remote server, in the sample above all requests that contain myfile.js will be replaced by the version served from the local server. This could as well be any other remote machine serving the file, as the request is proxied again ([P] flag). Finally caching is avoided by setting all files to expire right now (while this adds more load to the proxy it is not that bad to do during testing).

Now the proxy has to be used in the browser or application of choice; once the proxy settings are changed within the networks settings the access log of Apache should become quite busy when browsing around and, depending on your mod_rewrite settings above, some requests should be replaced with the local copy of a file, making debugging way easier.

Of course the drawbacks of the poor man’s solution are that Apache has to be reloaded in case the RewriteRules change and changing the configuration is not as comfortable as with the dedicated proxy solutions mentioned above. Nevertheless this solution works, is fast and very reliable… and free

Setting up AuthzSVNAccessFile support for Subversion (SVN) should not be that hard, right? Plenty of documentation exists… but there is one pitfall – if you define access for certain repository directories make sure the path does not contain a trailing slash!

If you don’t you will see this error message:

Sending folder/design/readme.txt
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for ‘/myrepos/!svn/ver/501/trunk/folder/design/readme.txt’
svn: Your commit message was left in a temporary file:
svn: ‘/tmp/trunk/svn-commit.2.tmp’

Here is a simple AuthzSVNAccessFile sample file showing the issue:

[groups]
developers = mike, peter
designers = marc

[/]
@developers = rw
* = r

# This will not work!
[myrepos:/trunk/folder/design/]
@designers = rw

# Just leave out the trailing slash!
[myrepos:/trunk/folder/design]
@designers = rw

But it’s always just a comma, right?

Yesterdays bug within the MANIFEST.MF file made me remember another bug that took quite some time to fix… let’s see if you can discover the bug in these three lines of code:

// domdoc is a DOM document
domdoc.doSomethingWithAttribute(“href”);
domdoc.doSomethingWithAttribute(“scr”);
domdoc.doSomethingWithAttribute(“action”);

Are you able to see the error?

My EAR package worked fine, until tonight during the deployment to another server infrastructure. How hard can a simple EAR update be? “Could not find symbol” somewhere next to a simple line initializing log4j. It complained about missing the Logger class.
A check in the EAR file revealed that the required jar files are all there. Still this error. But why?

Finally I figured out that the manifest file included all of the required libraries in the classpath but missed the “.” to include the current directory as well, after adding it everything worked out:

Class-Path: log4j.jar lib.jar .

Took some time to perform a simple upgrade of an existing EAR file… because of such a simple error – so ensure your MANIFEST.MF file contains the dot!

To have my data secured I run (almost) daily backups using a custom script to my NAS system. Over there, at the great, little Linux box, runs a script that does daily increments using rsnapshot. There is also another script that keeps a copy on an external WebDAV server up-to date.
Implementing this was not that simple – as the NAS itself does not support mounting WebDAV servers natively I had to use a PHP script, which required patching the PEAR WebDav Client (digest auth, block size, stat entries) but eventually I got it working at a reasonable speed (8k block size does not make sense for a HTTP based protocol!). The big benefits – my computers don’t have to run to upload the data, the NAS is doing that work and it is running 24/7 anyway.

End of story, zero maintenance required.

Until I tried to switch from Bingodisk to Apple’s iDisk.

For some reason the backup on the iDisk always included hidden files, despite the fact that they have not been changed and already existed on the disk. Some simple investigation has shown that the iDisk server simply did not return any file that started with a dot (.). But why?
Packet sniffing revealed that there are some differences between the PHP request and the one sent by OS X, but even after modifying the PHP code there were no hidden files included. Last difference – the mysterious X-Source-Id header – but adding that also had no impact. Eventually, after digging in the source code, I figured the change that is needed – as stated on top of the InitUserAgentHeaderValue function:

IMPORTANT: The user-agent header MUST start with the
product token “WebDAVFS” because there are WebDAV servers
that special case this client.

Clear, concise and exactly what I needed to do – as soon as I sent this header iDisk responded with a file listing including hidden files!
I still have no clue why iDisk makes this difference, but it is good to know how to be able to run full backups including hidden files over WebDAV!

The PHP development team would like to announce the immediate availability of PHP 4.4.9. It continues to improve the security and the stability of the 4.4 branch and all users are strongly encouraged to upgrade to it as soon as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last PHP 4.4 release.

Finally. PHP5 is out there since quite some time and finally the old, legacy version is gone. Hopefully all hosting providers out there will upgrade in the next few weeks so all users can start leveraging the new, great features of PHP5. It’s worth it and upgrading is really simple!

Last night I had an idea about a project I’m working on and how to make this extensible and flexible by using JavaScript code snippets which are to be added to the Java code. Sounds like a crazy idea but I remembered Mozilla Rhino which allows executing JavaScript from within Java. Issue 1 solved.

Also I’m a great fan of the jQuery library and would most probably like to use it on the server side to perform modifications – saves a lot of time in working with the DOM. Luckily I also remembered a post of John Resig which explains exactly that issue (ok, Google helped me to find it ) – executing jQuery inside of Rhino. Using an application server like Jaxer is no option as the server environment is given. Issue 2 solved.

So, downloading Rhino, downloading env.js, downloading jquery.js, putting the sample together and, guess what, nothing worked. Uff. Even simple selectors like jQuery(‘div’).length always returned 0. After a little investigation I figured out that up to jQuery version 1.2.1 it worked like a charm, but the newer versions did not work anymore. But why? Hard to figure if there are not error messages shown.

What to do? Firing of a note to John Resig and – surprise – he wrote back within a few minutes, pointing me to a new version of env.js which also works with newer versions of jQuery.

THANKS John!

So grab the new version of env.js and start using jQuery 1.2.6 on the server right now!