killbill / killbill-plugin-framework-java Goto Github PK
View Code? Open in Web Editor NEWFramework to write Kill Bill plugins
Home Page: https://killbill.io
License: Apache License 2.0
Framework to write Kill Bill plugins
Home Page: https://killbill.io
License: Apache License 2.0
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";
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
.
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());
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.
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.
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?
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
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
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.
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:
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.
See
Consider both public T withTiers(final Tier[] tiers)
and public T withTiers(final List<Tier> tiers)
.
PluginX
classes have long constructions and no setter methods: it's difficult to just set the data you need in plugins or unit tests.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
In the same way we generated POJOs under boilerplate
for killbill-api
repo, we should do the same for killbill-plugin-api interfaces
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?
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
.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.