Transfer of "The DAO" tokens from your local wallet to another Ethereum address using geth

Unable to transfer DAO tokens using the Mist Wallet

Fascinated by the idea of a distributed autonomous organization I bought some DAO tokens sending ethereum money to the address 0xbb9bc244d798123fde783fcc1c72d3bb8c189413 as explained by The DAO.
Due to the nice GUI I decided to use the Mist Wallet to maintain my ethereum and to do money transfers. The voting page of the project explains quite well how to configure mist to track your DAO. In combination with the getting started article on howto build your own crypto currency it should be quite clear how to setup the mist wallet and how to transfer DAO tokens to another address. However for the time being it does not work on my mac with mist wallet 0.7.4. The wallet simply hangs when doing the transfer.

Falling back to the command line

As an alternative it is also possible to use the command line tool geth to do the transfer. If you have not yet installed it you can follow the instructions on the geth github page.
The following steps need to be performed in order to transfer The DAO tokens from your local wallet to another address (e.g. on the poloniex exchange):

1. First create a file with the name password containing the password of your ethereum wallet followed by a newline:
   $ vi password
2. Open a terminal and unlock your local wallet. Note that the hex address in the following example should be the address of your local wallet account.
   $ geth --password password --unlock 0x0df977bb21cf972a538187f72299614121549450
3. In another terminal attach to the running geth instance.
   $ geth attach
4. The command opens an interactive shell. In this shell define a variable that holds the ABI of The DAO by pasting the json content (do not add quotes) from the following address: https://gist.github.com/fivedogit/4f3e9a035262b99b2e7356a4fdf6dd34
   $ var abi = <pasted json content>;
5. Define the contract using the fixed The DAO address
   $ var contract = web3.eth.contract(abi).at("0xbb9bc244d798123fde783fcc1c72d3bb8c189413");
6. Check the balance of your DAO tokens in your local wallet. If you have tokens associated with your ethereum address the value should be greater than 0. Note that the result must be devided by 10^16.
   $ contract.balanceOf("0x0df977bb21cf972a538187f72299614121549450")/10000000000000000;
7. Now in order to transfer the tokens to a poloniex deposit address first login and identify the address in the balances section of your poloniex account by clicking Deposit in the line for DAO. For this example we assume a deposit address of 0x8686c1799fad1a10f044b64533ecf0200416fc50.
8. Execute the following command to transfer 14000 tokens to this address.
   $ contract.transfer("0x8686c1799fad1a10f044b64533ecf0200416fc50", 140000000000000000000, {from:"0x0df977bb21cf972a538187f72299614121549450"});
9. Recheck that your balance is now 0
   $ contract.balanceOf("0x0df977bb21cf972a538187f72299614121549450")/10000000000000000;
10. It can take about an hour until the tokens are transferred.
11. After you are done do not forget to remove the password file
    $ rm password

Testing private methods in Java and Groovy

If you search the internet for the topic testing private methods you will find several opinions if this is good practice or not. Some people even consider it a misconception. I personally think that it is a good idea to encapsulate logic that makes only sense in the context of a single class into a private method. If the code inside of this method exceeds a certain complexity it should be tested.

In this post however I do not want to start a discussion on this topic but show how it can be done easily in Groovy and Java. Let's have a look at the following code:


public class SomeClass {
  private String methodToBeTested(String input) {
    return input.toLowerCase(); 
  } 
}

// inside of a test
SomeClass someClass = new SomeClass();
assert "foo" == someClass.methodToBeTested("Foo");

If you run this code in Groovy you may expect an Error because the test calls a private method of SomeClass. However as of Groovy 2.1.9 this is currently not the case due to a bug in Groovy:
http://jira.codehaus.org/browse/GROOVY-1875
Consequently testing private methods in Groovy currently is really simple: just do it.

However if SomeClass is a class produced by the Java compiler the test will fail with an error like this:

methodToBeTested(java.lang.String) has private access in SomeClass         someClass.methodToBeTested("Foo");

The Groovy developers are working on a fix for the issue that will hopefully make it into Groovy 3. So the Groovy code shown above is eventually not compatible with future Groovy releases.

To overcome this testing problem one can use the Java Reflection API.
The test code must be changed like this:

// inside of a test SomeClass
someClass = new SomeClass();
Method method = SomeClass.class.getDeclaredMethod("methodToBeTested", String.class)
method.setAccessible(true);
assert "foo" == method.invoke(someClass, "Foo");

Note that the reflection methods can throw several Exceptions. If the test is written in Java these must be caught or the test method must be adjusted accordingly.

Tracking Session Lifecycle in Grails

Web applications often need to keep track when new user sessions are created and when user sessions are terminated - either by timing out or by active invalidation.
The Java Servlet Specification defines Event Listeners for this purpose. Have a look at this article for an introduction on how to utilize these servlet technologies.

I want to explain here how to integrate HttpSessionListeners smoothly with Grails.

We start by registering a listener in the deployment descriptor - the file web.xml.
By default this file is not visible when developing with Grails since it is generated dynamically. You can get a static version by executing the following command in the application's root directory:

grails install-templates

Instead of executing this command and creating a static web.xml file we are going to choose the more modular approach of extending the web.xml generation process.

The first thing to do is to create the file _Events.groovy in the scripts directory of the application root. Note that this directory was created when executing grails create-app. The contents of _Events.groovy should look something like this:

import groovy.xml.StreamingMarkupBuilder
eventWebXmlEnd = {String tmpfile -> 
  def root = new XmlSlurper().parse(webXmlFile)
  root.appendNode {
    'listener' { 
      'listener-class' (
        'org.test.MyHttpSessionListener'
      ) 
    }
  } 
  webXmlFile.text = new StreamingMarkupBuilder().bind {
    mkp.declareNamespace(
      "": "http://java.sun.com/xml/ns/j2ee")
    mkp.yield(root) 
  }
}

This defines a closure that is called by the Grails build mechanism right after creation of web.xml. In the closure Groovy's XmlSlurper is used to parse the web.xml into a tree data structure. Xml elements for listener and listener-class are added and the tree data structure is written back using Groovy's StreamingMarkupBuilder.

The class org.test.MyHttpSessionListener is registered as event listener.
The file  src/groovy/org/test/MyHttpSessionListener.groovy contains this class. Obviously the org/test part of the path depends on the package name you want to choose. The file's contents should look like this:

package org.test

import org.codehaus.groovy.grails.commons.ApplicationHolder
import javax.servlet.http.HttpSession
import javax.servlet.http.HttpSessionEvent
import javax.servlet.http.HttpSessionListener

class MyHttpSessionListener implements HttpSessionListener {
  HttpSessionService httpSessionService
  

  // called by servlet container upon session creation

  void sessionCreated(HttpSessionEvent event) {
    HttpSession session = event.getSession()
    getHttpSessionService().sessionCreated(session)
  }

  // called by servlet container upon session destruction

  void sessionDestroyed(HttpSessionEvent event) {
    HttpSession session = event.getSession()

    getHttpSessionService().sessionDestroyed(session)
  }

  private synchronized HttpSessionService

  getHttpSessionService() {

    if (httpSessionService == null) {
      httpSessionService =

        (HttpSessionService) ApplicationHolder

        .getApplication().getMainContext()

        .getBean("httpSessionService")
    }
    return httpSessionService
  }
}

The class implements the sessionCreated and sessionDestroyed methods as defined in the HttpSessionListener interface. These methods are called by the servlet container upon session creation and destruction. However to integrate our listener with the rest of the Grails artefacts it would be nicer if conventional Grails Service methods were called on these events.

To achieve the desired Service calls we cannot utilize Spring injections in our SessionListener. We therefore manually fetch a bean called httpSessionService from the application's MainContext. This bean is a conventional Grails Service that we have to implement in a file called grails-app/services/org/test/HttpSessionService.groovy.  The file could have the following contents:

package org.test

import javax.servlet.http.HttpSession

class HttpSessionService {

  // method called upon session creation
  def sessionCreated(HttpSession session) {
    log.info("Session created: "+session.id)
  }

  //method called upon session destruction
  def sessionDestroyed(HttpSession session) {
    log.info("Session destroyed: "+session.id)
  }
}

Other services can be injected into the HttpSessionService and relevant business logic can be called from the sessionCreated and sessionDestroyed Service methods.

Oliver Wahlen's Blog Online

So this is my first post on Blogger.
As an IT consultant I have done several projects using Netbeans and its Visual Web JSF framework based on the Woodstock components.
I think that JSF is in general one of the best approaches to create robust web applications.

However the whole web technology sector is evolving with an enormous speed and to stay "in business" developers have to get comfortable with new technologies at an enormous rate.

I want to use this blog for two purposes:

1. to present new technology approaches, and to help developers getting comfortable with these technologies.
2. to share my personal technology evaluation results with others and to challenge other opinions. I think such discussions will help people to get a better level of judgement concerning state of the arte technologies. Therefore I encourage everybody to comment my posts!
   

And now: Happy blogging!

Netbeans Visual Web Tables with thousands of records

Maybe you have noticed that the table component in Netbeans visual
web tends to become quite slow if it has to deal with a huge amount of
records (e.g. coming from a database).
This is true even if pagination is used.

The reason is that the typical dataproviders (e.g. ObjectArrayDataProvider) on the server side require a complete fetch of all data from the database.
Based on this data they analyze the amount of records which in turn is used to operate the augmented table header and the pagination controls.
Thus the application does not only become slow (because of the sql operations) but also consumes a large amount of memory.

To overcome this problem I have created a new dataprovider called ObjectControllerDataprovider.
Like all the other dataprovider this class can directly be used in the table layout of the visual table component.
This ObjectControllerDataprovider is in turn connected an ObjectController.
In more detail the ObjectControllerDataprovider is connected to a class that is to be written manually which extends the abstract ObjectController class.
The manual written class finally contains the functionality to efficiently retrieve small pages from a database utilizing a caching window concept.

You can download a working Netbeans 6.1 example project using the new dataprovider from the following link: http://sites.google.com/site/owahlen/Home/ObjectControllerTest.tar.gz