Make better use of Jackson

[msgilligan]

Better use of Jackson will help us to:

1. Eliminate repetitive conversion code from many methods
2. Replace remaining Maps with strongly-typed POJOs.

[msgilligan]

Progress report

1. Create POJOs for JsonRpcRequest and JsonRpcResponse: 0523aeb
2. Start customizing the ObjectMapper with a CoinDeserializer: 91f7cc1
3. Create and use more serializers and deserializers: 79d27ea
4. More deserializers, custom "Module": 0d0d663
5. Deserialize listunspent directly to List<UnspentOutput>: 8d88420

What do you think, @dexX7 ?

[msgilligan]

TODO:

1. Split current bitcoinj-json project into two modules: -json (jackson stuff) and -server (services)
2. Make bitcoinj-rpcclient depend on bitcoinj-json
3. Move serializers and deserializers from -rpcclient into a Jackson module in bitcoinj-json.

[dexX7]

These changes are fantastic, really a great improvement!

In Omni Core we currently have a few results where some fields are omitted, depending on the state, e.g. whether a crowdsale is closed, or active, whether a transaction is confirmed or unconfirmed, which makes mapping to plain data objects probably pretty difficult. Makes me wonder..

[msgilligan]

POJOs to create:

1. Block object - getBlock -- Done
2. List of block hashes - setGenerate -- Done
3. SignedRawTransaction - signRawTransaction -- Done
4. List - listReceivedByAddress -- Done
5. TxOutInfo - getTxOut -- Done
6. ServerInfo - getInfo -- Done
7. ChainTip - getChainTips -- Done
8. RawTransactionInfo - getRawTransactionMap -- Done
9. WalletTransactionInfo- getTransaction -- Done

Note: These changes are changing the API.

[msgilligan]

some fields are omitted, depending on the state ... which makes mapping to plain data objects probably pretty difficult.

Can't those fields just be nullable in the POJO?

[dexX7]

List of UTXO - getTxOut

It returns a single unspent output or null, if the output is spent.

Can't those fields just be nullable in the POJO?

Ah, sure.

[msgilligan]

List of UTXO - getTxOut

It returns a single unspent output or null, if the output is spent.

Thanks. Fixed, above.

[msgilligan]

@dexX7 Finished all but (8) and (9) in the POJOs to create list. Any ideas or suggestions on (8) or (9)?

Update: I think the POJO definitions for (8) and (9) are definitely needed for the server implementation. The server will need to them to implement the standard JSON-RPC results and they can also be used for serializing JSON for the STOMP feed of transactions.

[dexX7]

If getTransaction refers to gettransaction, then this is a call to get a wallet transaction, which has some wallet specific information (such as listing potential conflicts, or the time of creation). If getRawTransactionMap refers to getrawtransaction, then it might either be mapped to a BitcoinJ transaction, or a new type: the verbose version has information about the chain (blocktime, blockhash, confirmations (stateful)).

[msgilligan]

Yes. In addition to mapping to org.bitcoinj.core.Transaction we're going to need to create POJOs for both gettransaction and getrawtransaction. They're required for making the server version and, as you point out, they contain info that is not available in bitcoinj's Transaction.

[msgilligan]

Finished in v0.0.10: ff680a0.