killbill / killbill-plugin-framework-java Goto Github PK

View Code? Open in Web Editor NEW

9.0 8.0 24.0 1.05 MB

Framework to write Kill Bill plugins

Home Page: https://killbill.io

License: Apache License 2.0

Java 100.00%

killbill subscriptions billing payments

killbill-plugin-framework-java's Introduction

killbill-plugin-framework-java

Convenience library to help write Kill Bill plugins.

Kill Bill compatibility

Framework version	Kill Bill version
0.3.y	0.16.z
1.2.y	0.18.z
2.x.y	0.19.z
3.x.y	0.20.z
4.1.y	0.22.z
4.2.y	0.22.z
5.0.y	0.24.z
5.1.y	0.24.z

We've upgraded numerous dependencies in 4.2.x (required for Java 11 support).

Usage

Add the library to your plugin:

<dependency>
    <groupId>org.kill-bill.billing.plugin.java</groupId>
    <artifactId>killbill-base-plugin</artifactId>
    <version>... release version ...</version>
</dependency>
<dependency>
    <groupId>org.kill-bill.billing.plugin.java</groupId>
    <artifactId>killbill-base-plugin</artifactId>
    <version>... release version ...</version>
    <type>test-jar</type>
    <scope>test</scope>
</dependency>

About

Kill Bill is the leading Open-Source Subscription Billing & Payments Platform. For more information about the project, go to https://killbill.io/.

killbill-plugin-framework-java's People

Contributors

Stargazers

Watchers

killbill-plugin-framework-java's Issues

Queryparams and headers arguments switched

Line 167 of org.killbill.billing.plugin.util.http.HttpClient reverses the queryparams and headers arguments. When I pass these two into doCallAndReturn they end up interchanged when they reach the doCall() method on line 170. If I reverse the arguments (ie pass params as headers and vv) then everything works.

Generate POJOs for killbill-plugin-api interfaces

In the same way we generated POJOs under boilerplate for killbill-api repo, we should do the same for killbill-plugin-api interfaces

Integrate api pojos

This task consists in leveraging the api-pojo code generation tool to generate all the POJOs associated with our killbill-api interfaces, and check them in as part of this repo.

Then, go through this code and check what existing POJOs we had created by hand and either replace or extend (if there is some business logic) those. Doing a quick inspection, I see the following candidates - to be confirmed:

PluginDryRunArguments
PluginTag
PluginEntitlementSpecifier
PluginPaymentOptions
PluginPlanPhasePriceOverride
PluginCustomField
PluginAccountData
PluginPaymentTransactionInfoPlugin
PluginHostedPaymentPageFormDescriptor
PluginPaymentMethodPlugin
PluginGatewayNotification
PluginPaymentMethodInfoPlugin
PluginCallContext
PluginTenantContext
PluginInvoiceItem

Leverage plugin framework inside (test) catalog plugin

The current repo killbill-catalog-plugin-test is not using this repo as a base.

We should leverage all the new api POJOs (see #54) and stop pulling the classes from the killbill repo, i.e remove this dependency.

However, such dependency is also used to deserialize the XML catalog, by leveraging all the JAXB annotation. Perhaps instead we could use as a source JSON catalog files (see https://killbill.github.io/slate/#catalog-retrieve-the-catalog-as-json to extract such catalog json), and from the json data write a json parser leveraging jackson and the new api POJOs from this repo.

Add support for YAML config

Today, Java plugins expect Java properties file for their configuration. We should also add support for YAML, which would simplify things like region-specific configuration (#11):

common: &defaults
  username: XXX
  password: YYY

us-east-1:
  <<: *defaults
  paymentUrl: ZZZ1

us-west-1:
  <<: *defaults
  paymentUrl: ZZZ2

add follow redirect feature to HttpClient

Currently, base plugin HttpClient not get redirected if HTTP response code is 30x. Instead, it's just return something like:

<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
</body>
</html>

We need to add .followRedirects(HttpClient.Redirect.NORMAL) when building an org.killbill.billing.plugin.util.http.HttpClient.

Add support for encrypted properties

Similar to killbill/killbill#777, we should support encrypted key/values properties.

To do it, the plugin configuration handlers could look for property values with a specific marker (e.g. ENC(...) and load the proper decryption algorithm based on a global configuration.

Investigate using Spring into KB plugins

Add support for List in boilerplate code

See

killbill-plugin-framework-java/src/main/java/org/killbill/billing/catalog/api/boilerplate/UsageImp.java

Line 310 in c0f16f8

public T withTiers(final Tier[] tiers) {

Consider both public T withTiers(final Tier[] tiers) and public T withTiers(final List<Tier> tiers).

Challenges in using some domain classes

PluginX classes have long constructions and no setter methods: it's difficult to just set the data you need in plugins or unit tests.
A lot of default implementations are missing (e.g. catalog POJO).

OSGI Import-Package directives

I added the OSGI Import-Package directives as specified in the README.md, but got this error:

2016-01-27 12:51:42,041 [bus_ext_events-th] WARN o.killbill.billing.osgi.FileInstall - Unable to start bundle org.osgi.framework.BundleException: Unresolved constraint in bundle org.kill-bill.billing.plugin.java.catalog.test [22]: Unable to resolve 22.0: missing requirement [22.0] osgi.wiring.package; (osgi.wiring.package=org.killbill.billing.routing.plugin.api) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4002) at org.apache.felix.framework.Felix.startBundle(Felix.java:2045) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963) ...

I removed org.killbill.billing.routing.plugin.api from the Import-Package and my plugin started up fine. Not sure where that package actually comes from (didn't see it in killbill-api) - should it be removed from the README instructions?

Wrong computation for CC_LAST_4

See PluginPaymentDao line 163

It currently reads

final String ccLast4 = ccNumber == null ? null :
        ccNumber.substring(ccNumber.length() - 5, ccNumber.length() - 1);

Which produces for a card like 4111111111123456 a value of 2345. It should read:

final String ccLast4 = ccNumber == null ? null :
        ccNumber.substring(ccNumber.length() - 4, ccNumber.length());

Set default payment method - bug

killbill-plugin-framework-java/src/main/java/org/killbill/billing/plugin/dao/payment/PluginPaymentDao.java

Lines 330 to 345 in e903d13

 public void run(final Configuration configuration) throws Exception { 

 DSL.using(conn, dialect, settings) 

 .update(paymentMethodsTable) 

 .set(DSL.field(paymentMethodsTable.getName() + "." + IS_DEFAULT), FALSE) 

 .set(DSL.field(paymentMethodsTable.getName() + "." + UPDATED_DATE), toTimestamp(utcNow)) 

 .where(DSL.field(paymentMethodsTable.getName() + "." + KB_PAYMENT_METHOD_ID).notEqual(kbPaymentMethodId.toString())) 

 .and(DSL.field(paymentMethodsTable.getName() + "." + KB_TENANT_ID).equal(kbTenantId.toString())) 

 .execute(); 

 DSL.using(conn, dialect, settings) 

 .update(paymentMethodsTable) 

 .set(DSL.field(paymentMethodsTable.getName() + "." + IS_DEFAULT), TRUE) 

 .set(DSL.field(paymentMethodsTable.getName() + "." + UPDATED_DATE), toTimestamp(utcNow)) 

 .where(DSL.field(paymentMethodsTable.getName() + "." + KB_PAYMENT_METHOD_ID).equal(kbPaymentMethodId.toString())) 

 .and(DSL.field(paymentMethodsTable.getName() + "." + KB_TENANT_ID).equal(kbTenantId.toString())) 

 .execute();

Duplicate keys for CC_START_(MONTH|YEAR)

See PluginPaymentApi, lines 59 and 60

It currently reads

    public static final String PROPERTY_CC_START_MONTH = "ccExpirationMonth";
    public static final String PROPERTY_CC_START_YEAR = "ccExpirationYear";

It should read:

    public static final String PROPERTY_CC_START_MONTH = "ccStartMonth";
    public static final String PROPERTY_CC_START_YEAR = "ccStartYear";

use java api and remove guava

We removed all guava dependencies in killbill, killbill-commons, killbill-platform and some others repositories as part of killbill/killbill#1615. But looks like this repository (killbill-plugin-framework-java) still contains guava classes in code base.

Type Implementations

The createAccount method on the accountUserApi needs a parameter of the type AccountData for which only the interface is defined. Not sure if i'm missing something here but i can't find a existing implementation for AccountData (and also other types) and ended up implementing one myself.

Is there an existing implementation somewhere?

TestUtils.buildAccount should create a valid email address

See https://github.com/killbill/killbill-stripe-plugin/pull/38/files#diff-99e724f0e225bb34748719590ce42120740374d1c69d995b635c7ac5e91a2860R66.

PostgreSQL support

New utilities to extract from Analytics plugin:

public static EmbeddedDB.DBEngine getDBEngine(DataSource dataSource) throws SQLException
public static SQLDialect getSQLDialect(EmbeddedDB.DBEngine dbEngine)

Add new constructor to PluginPaymentDao:

public PluginPaymentDao(RESP_T responsesTable, PM_T paymentMethodsTable, DataSource dataSource, SQLDialect dialect, Settings settings) throws SQLException

Change PluginPaymentDao to not prefix fields in case of non-ambiguous SQL (DSL.field(responsesTable.getName() + "." + KB_ACCOUNT_ID) -> DSL.field(KB_ACCOUNT_ID)).

Add utility to load a global JOOQ settings.xml and parse it to generate the right Settings.

New API (helper) to retrieve Kill Bill region

Kill Bill should export the region it's deployed in (colo, us-east-1, etc.).

Implementation could be as easy as expecting a system property org.killbill.server.region (which we could also expose in KillbillServerConfig) and retrieving it from OSGIConfigProperties.

Plugins could then use it for region-specific properties, e.g. the Adyen plugin could look for org.killbill.billing.plugin.adyen.{region}.paymentUrl on top of org.killbill.billing.plugin.adyen.paymentUrl to see if a region-specific URL is defined.

The UTF8UrlDecoder can not decode the multi-byte characters

Hi @pierre ,

Is there any reason that we wrote our own decoder instead of using the java provided function?
And I found our version of decoder can not decode multi-byte characters.
https://github.com/killbill/killbill-plugin-framework-java/blob/master/src/main/java/org/killbill/billing/plugin/util/http/UTF8UrlDecoder.java

You can check the test as below:

package org.killbill.billing.plugin.util.http;

import java.io.UnsupportedEncodingException;
import java.net.URLDecoder;
import java.net.URLEncoder;

import org.testng.Assert;
import org.testng.annotations.Test;

public class TestUTF8URLDecoder {

    @Test(groups = "fast")
    public void testOf() {
        verifyEncoding("abcdefghijklmnopqrstuvwxyz0123456789");
        verifyEncoding("ïłéà");
    }

    private void verifyEncoding(String input) {
        try {
            String encoded = URLEncoder.encode(input, "UTF-8");
            System.out.println(encoded);
            Assert.assertEquals(UTF8UrlDecoder.decode(encoded).toString(), URLDecoder.decode(encoded, "UTF-8"));
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }
}

The output is:

[TestNG] Running:
  /Users/unieagle/Library/Caches/IntelliJIdea15/temp-testng-customsuite.xml
abcdefghijklmnopqrstuvwxyz0123456789
%C3%AF%C5%82%C3%A9%C3%A0

java.lang.AssertionError: expected [ïłéà] but found [Ã¯Å�Ã©Ã ]
Expected :ïłéà
Actual   :Ã¯Å�Ã©Ã 

===============================================
Default Suite
Total tests run: 1, Failures: 1, Skips: 0
===============================================

Process finished with exit code 0

automate killbill-api implementation generation

Currently, killbill-api implementation classes used in killbill-base-plugin/killbill-plugin-framework-java generated by api-pojos (see packages name that ends with boilerplace). Unfortunately, all of this involve manual steps described in example document. We should able to:

Automate it with only single (or a couple of) step(s).
(and/or) integrate it with github action.

See Original discussion here.

	public void run(final Configuration configuration) throws Exception {
	DSL.using(conn, dialect, settings)
	.update(paymentMethodsTable)
	.set(DSL.field(paymentMethodsTable.getName() + "." + IS_DEFAULT), FALSE)
	.set(DSL.field(paymentMethodsTable.getName() + "." + UPDATED_DATE), toTimestamp(utcNow))
	.where(DSL.field(paymentMethodsTable.getName() + "." + KB_PAYMENT_METHOD_ID).notEqual(kbPaymentMethodId.toString()))
	.and(DSL.field(paymentMethodsTable.getName() + "." + KB_TENANT_ID).equal(kbTenantId.toString()))
	.execute();

	DSL.using(conn, dialect, settings)
	.update(paymentMethodsTable)
	.set(DSL.field(paymentMethodsTable.getName() + "." + IS_DEFAULT), TRUE)
	.set(DSL.field(paymentMethodsTable.getName() + "." + UPDATED_DATE), toTimestamp(utcNow))
	.where(DSL.field(paymentMethodsTable.getName() + "." + KB_PAYMENT_METHOD_ID).equal(kbPaymentMethodId.toString()))
	.and(DSL.field(paymentMethodsTable.getName() + "." + KB_TENANT_ID).equal(kbTenantId.toString()))
	.execute();