killbill-memoizeit

Payment SQL renaming Remove payment state_name NON NULL constraints …

(code is working that way)

Rework Payment exception handling for state machine operation …

and interraction with thread dispatcher code.

The state machine code rely on OperationResult and OperationException to correctly route to the next state so it crucial to
throw correct exception to land in the correct state.

Fix erroneous file deletion

API change for PaymentStatus -> TransactionStatus API change …

for PaymentStatus -> TransactionStatus (2)

Initial renaming from 'direct'Payment/Transaction -> Payment/Transaction …

(DDL, and DAO layer)
Review for DDL (add indexes, remove unused fields, ...)

Api changes for Payment

Code review for new payment work Conflicts: beatrix/src/test/java/org/killbill/billing/beatrix/util/AuditChecker.java beatrix/src/test/java/org/killbill/billing/beatrix/util/PaymentChecker.java beatrix/src/test/java/org/killbill/billing/beatrix/util/RefundChecker.java

payment: initial version using state machines This also: * …

extracts the platform specific code
* adds DirectPaymentTransaction#getExternalKey, see https://github.com/killbill/killbill/issues/180
* fixes compilation errors with the latest Java client (PaymentMethodProperties has been renamed PluginProperty)
* allows override of payment method id, see https://github.com/killbill/killbill/issues/177
* exports payment plugin properties in direct payment resources, see https://github.com/killbill/killbill/issues/185
* cleans up credit and refund operations, see https://github.com/killbill/killbill/issues/187
* deprecates RefundInfoPlugin for PaymentInfoPlugin
* adds BUS events for all direct payments calls. Note that I have
re-used the existing events for now. It may be desirable to expose
more information in the future (like the type of transaction). Clients
do have the direct payment id though, so they can retrieve the information
if needed. See https://github.com/killbill/killbill/issues/179

Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>

fixes #170 (Hopefully this is time this is for real) Modified …

assertion in test testRegressionFor170 so that it makes sense and fixes code to make sure the (correct) test pass.
The short story is that it is somehow complicated because we need to support cases where any form of existing invoices with any form
of billing events (forming the proposed events) should trigger a correct invoice.

fixes #170 Invoice fix to make sure that overlapping full repair …

scenarii are correctly handled.
Added invoice specific unit test to verify that behavior (test testOverlappingRepair in TestSubscriptionItemTree)
Ported regression testRegressionFor170 in TestDefaultInvoiceGenerator
Added extra invoice generation in all beatrix tests to verify wach test end up in a stable state

Disable flaky beatrix overdue tests @see #174