commercetools / commercetools-jvm-sdk

The e-commerce SDK from commercetools running on the Java virtual machine.
https://commercetools.github.io/commercetools-jvm-sdk/apidocs/index.html
Other
62 stars 40 forks source link

java.lang.NoSuchMethodError: io.sphere.sdk.payments.PaymentDraftBuilder.build()Lio/sphere/sdk/payments/PaymentDraft; #1284

Closed heshamMassoud closed 7 years ago

heshamMassoud commented 7 years ago

Hi,

When using jvm sdk version >= 1.7.0 with Payone Integration Services, when we create a payment as follows:

CreatePaymentDataBuilder paymentDataBuilder = CreatePaymentDataBuilder.of(sphereClient, selectedPaymentMethod, cart, orderNumber);
PaymentCreationResult paymentCreationResult = getPaymentAdapterService().createPayment(paymentDataBuilder.build()).toCompletableFuture().join();

we get the following exception:

Caused by: java.lang.NoSuchMethodError: io.sphere.sdk.payments.PaymentDraftBuilder.build()Lio/sphere/sdk/payments/PaymentDraft;
    at com.commercetools.sunrise.payment.methods.CreatePaymentMethodBase.removePaymentsAndCreateNew(CreatePaymentMethodBase.java:40)
    at com.commercetools.sunrise.payment.payone.methods.PayoneBanktransferInAdvanceCreatePaymentProvider.lambda$create$1(PayoneBanktransferInAdvanceCreatePaymentProvider.java:37)
    at com.commercetools.sunrise.payment.service.PaymentAdapterServiceImpl.createPayment(PaymentAdapterServiceImpl.java:64)

Seems like there is a problem with how the PaymentDraftBuilder is generated (maybe?), especially that the method reference has this weird ending

io.sphere.sdk.payments.PaymentDraftBuilder.build()Lio/sphere/sdk/payments/PaymentDraft;

Thanks!

heshamMassoud commented 7 years ago

@lauraluiz It appears that the problem was that the Payment Module was using a version of the SDK that is earlier that 1.7 (which introduced the draft builders code generation). Maybe it should be mentioned in the release notes that it's a breaking change :)

cc @ahalberkamp @andrii-kovalenko-ct

lauraluiz commented 7 years ago

Mentioned in the Release Notes that this can be a breaking change http://commercetools.github.io/commercetools-jvm-sdk/apidocs/io/sphere/sdk/meta/ReleaseNotes.html

The problem was simply that the method is now returning a covariant of the previous type (PaymentDraftDsl --|> PaymentDraft), which is apparently harmless but on bytecode level the method signature changes.