Make better use of Jackson about consensusj HOT 11 CLOSED

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 ?

from consensusj.

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.

from consensusj.

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..

from consensusj.

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.

from consensusj.

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?

from consensusj.

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.

from consensusj.

List of UTXO - getTxOut

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

Thanks. Fixed, above.

from consensusj.

@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.

from consensusj.

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)).

from consensusj.

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.

from consensusj.

Finished in v0.0.10: ff680a0.

from consensusj.