hyperledger / fabric-chaincode-java Goto Github PK

The choice of delimiter key used in the CompositeKey is subjective. The chaincode implementer may choose to have their own delimiter logic in place. The keys added in the CompositeKey would end up in the blockchain's state db, eventually in the blocks as well. The choice to application developers makes it possible for them to choose what keys are added in those structures.

I'm looking at version 2.3 but I think the behavior holds for the lastest version.

The following code is based on https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-basic/chaincode-java.

@DataType
public class Sale {
	public String getName() {
		System.out.println("getName");
		return getName();
	}
}

@Contract
public final class AssetTransfer implements ContractInterface {

    @Transaction(intent = Transaction.TYPE.EVALUATE)
    public Sale getSale(final Context ctx) {
        return new Sale();
    }
}

I deliberately wrote a recursion but it should be a factor because this method is not marked with @Property.

After I call peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}', I then check the docker logs by running (zsh)

docker logs $(docker ps -n 1 --filter 'name=dev-peer0.org1' --format '{{.ID}}') |& vim -

I see a huge number of output "getName", which indicates getName() is called although it's not marked with @Property.

In this example code, there is nothing going wrong. But if the method returns an object that requires another serialization or has cyclic reference, this unexpected call is very likely to cause uncatched StackOverflowError or other errors.

This log is from my real project. You can see I eventually get

thread[fabric-txinvoke:3,5,main] 05:37:40:138 severe  org.hyperledger.fabric.logger error                                              nulljava.lang.stackoverflowerror

infinite-call.log

I feel I should use the magic word "@JSONPropertyIgnore" on getName().

This secret word didn't appear on https://hyperledger-fabric.readthedocs.io/en/latest/search.html?q=JSONPropertyIgnore&check_keywords=yes nor this repo.

Should we add @JSONPropertyIgnore somewhere?

See https://github.com/hyperledger/fabric-rfcs/blob/main/text/0000-opentelemetry-tracing.md

Adding OpenTelemetry integration, starting with adding traces support for chaincodes.

When I deploy the java version asset-transfer-private-data chaincode in test-network, the index deployment was not successful. And the go version asset-transfer-private-data chaincode is OK.

Then, I want check the reason, but there are no java-version asset-transfer-ledger-quires chaincode. So I copied the index from go-version asset-transfer-ledger-quires chaincode to go-version asset-transfer-basic chaincode and java-version asset-transfer-basic chaincode. And I changed the field in the index.

The go-version asset-transfer-basic chaincode with index is OK. However, the java-version asset-transfer-basic chaincode with index was not successful as well.

Environment: Hyperledger Fabric release 2.2
chaincode A:

@Transaction()
public String invokeOtherContract(final Context ctx, final String chaincodeName, final String method) {
    System.out.printf("\n%s\n", chaincodeName);
    Response resp = ctx.getStub().invokeChaincode(chaincodeName, Arrays.asList(method.getBytes()));
    String payload = new String(resp.getPayload(), StandardCharsets.UTF_8);
    return payload;
}
@Transaction()
public String helloworld(final Context ctx){
    System.out.println("helloworld");
    return "helloworld";
}

chaincode B:

@Transaction()
public String callback(final Context ctx){
    Response resp = ctx.getStub().invokeChaincode("A", Arrays.asList("helloworld".getBytes()));
    return new String(resp.getPayload(), StandardCharsets.UTF_8);
}

I submit a transaction calling A.invokeOtherContract, an error occured.
According to https://lists.hyperledger.org/g/fabric/topic/question_about/87787297?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,87787297,previd=1639806725290257427,nextid=1638892803487662689&previd=1639806725290257427&nextid=1638892803487662689, a chaincode has a unique identifier in the network when it is running.

How this error happen? I'm quite confused with the way (in code) this error happens.

As mentioned here
https://hlf.readthedocs.io/en/latest/developapps/transactioncontext.html#stub
and also
https://github.com/hyperledger/fabric-chaincode-go/blob/main/shim/interfaces.go

The information about it only be usable in the outer most chaincode should be added

As a maintainer
I want a regularly scheduled build to be run
So that build issues caused by changing dependencies or infrastructure are identified quickly

Version: 2.2.0

One of my chaincode peers is occasionally failing transactions with the following error:

15:37:45:121 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got invoke routing request
15:37:45:122 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got the invoke request for:ProductContract:get [7LZ4W7MTRfgHU70ABNQf8Qv5KWHo3x9v]
15:37:45:125 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got routing:get:com.contracts.ProductContract
15:37:45:128 INFO    org.hyperledger.fabric.shim.impl.ChaincodeInvocationTask invoke                  Sending message to the peer 79e6be839fb05cde256d58750999c6f94654ebef51203e784e39dd94f053f84b
15:37:45:136 SEVERE  org.hyperledger.fabric.shim.impl.InvocationTaskManager sendToTask                Failed to send response to the task task 79e6be839fb05cde256d58750999c6f94654ebef51203e784e39dd94f053f84bTask hasmap missing entry
java.lang.InterruptedException: Task hasmap missing entry
        at org.hyperledger.fabric.shim.impl.InvocationTaskManager.sendToTask(InvocationTaskManager.java:191)
        at org.hyperledger.fabric.shim.impl.InvocationTaskManager.handleMsg(InvocationTaskManager.java:166)
        at org.hyperledger.fabric.shim.impl.InvocationTaskManager.onChaincodeMessage(InvocationTaskManager.java:139)
        at org.hyperledger.fabric.shim.impl.ChaincodeSupportClient$1.onNext(ChaincodeSupportClient.java:96)
        at org.hyperledger.fabric.shim.impl.ChaincodeSupportClient$1.onNext(ChaincodeSupportClient.java:92)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(ClientCalls.java:447)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInternal(ClientCallImpl.java:658)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(ClientCallImpl.java:643)
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)

The other chaincode peers successfully processed the transaction however, this one did not.

I'm trying to understand why this issue is occuring. It seems as though the task no longer exists to receive the chaincode message but I don't know enough as to what would cause this to happen.

I later start seeing it more and more and then eventually the peer times out every transaction. Perhaps this is unrelated but always seems to be the outcome.

As a maintainer
I want the fabric-javaenv Docker image to be built as part of the testing done on pull requests
So that the codebase contains valid Docker image configuration ready for release

Currently the only point in the workflow that the Docker image is built in when a release is created. This is not a good time to find out that the Docker image configuration contains errors!

With java records, getters are accessed fluently (e.g. getId() -> id()).

The current serializer requires traditional getters and is not compatible with standard records without explicitly adding getters to it.

As a contributor
I want integration tests to use the development chaincode Docker image
So that I can confirm that a release version of the codebase will function correctly

The chaincodes used by the integration tests run in microfab. This offers a functional Fabric environment and is extremely quick. However, the chaincode environment is not the same as the chaincode Docker image defined in fabric-chaincode-docker.

It might be sufficient for a smaller set of tests to use the development chaincode Docker image rather than have all integration tests run there. The scenarios should cover both Gradle and Maven chaincode to ensure that the image contents provide all the necessary tools.

As per https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/, OpenJDK is no more or will be shortly. A different way of saying this is that AdoptOpenJDK has gone End of Service.

https://adoptium.net/ is the new location to get these binaries.

The source code location of this is https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-docker/Dockerfile#L57.

It's worth putting into this issue that the Fabric Java SDK will need to compile/run in the updated environment, which will potentially have an impact on the amount of time it takes to finish this task. That is, Fabric SDK code may need to be updated before or with this change and I'm not sure how much code change is needed.

Visit the link https://github.com/hyperledger/fabric-chaincode-java this .
Now click on "documentation" links as mentioned below
https://hyperledger-fabric.readthedocs.io/en/latest/tutorial/commercial_paper.html
we will be redirected to Read the Docs " This page does not exist yet. " page.

Add the private data purge support.

ref hyperledger/fabric#2787

@bestbeforetoday thanks in advance for your time on this.

Two PRs open that have both passed the checks. Should be helpful for keeping us up-to-snuff on the security/dependency side of things:

#331

and

#332

Due to an issue with the Dependency Check tool, this has to be disabled to test the publishing..
When this is resolved - re-enable
jeremylong/DependencyCheck#5220

ChaincodeBase attempts to parse SSL certificates and keys provided by an external launcher in the following manner:

     final SslContext createSSLContext() throws IOException {
        final byte[] ckb = Files.readAllBytes(Paths.get(this.tlsClientKeyPath));
        final byte[] ccb = Files.readAllBytes(Paths.get(this.tlsClientCertPath));

         return GrpcSslContexts.forClient().trustManager(new File(this.tlsClientRootCertPath))
                .keyManager(new ByteArrayInputStream(Base64.getDecoder().decode(ccb)),
                        new ByteArrayInputStream(Base64.getDecoder().decode(ckb)))
                 .build();
     }

This fails, because the certs deployed by the external builder are in PEM format, but the code attempts to Base64 decode them.

The fix is obvious, and I have used it successfully in testing (however, I would have to jump through a bunch of hoops to contribute it, so someone else should probably do it).

Using 2.2.3LTS using the contract-api I have this method

   @Transaction(submit=false)
    public QueryResponse<String> paginatedRichQuery(Context ctx, String queryString, String pagesize, String passedBookmark) {
        logger.debug("Entering paginatedRichQuery with pagesize [" + pagesize + "] and query string: " + queryString);
        int pageSize = Integer.parseInt(pagesize);

        final QueryResultsIteratorWithMetadata<KeyValue> iterator = ctx.getStub().getQueryResultWithPagination(queryString, pageSize, passedBookmark);
        QueryResponseMetadata metadata = iterator.getMetadata();
        ArrayList<String> results = this.getAllResults(iterator);

        QueryResponse<String> response = new QueryResponse<String>(results.toArray(new String[results.size()]), new ResponseMetadata(metadata));
        logger.debug("Exiting paginatedRichQuery with response: " + response.toString());
        return response;
    }

QueryResponse is defined as follows

public class QueryResponse<T> {
    private T[] results;

    private ResponseMetadata responseMetadata;

    public QueryResponse(T[] results, ResponseMetadata responseMetadata) {
        this.results = results;
        this.responseMetadata = responseMetadata;
    }

    public T[] getResults() {
        return results;
    }

    public void setResults(T[] results) {
        this.results = results;
    }

    public ResponseMetadata getResponseMetadata() {
        return responseMetadata;
    }

    public void setResponseMetadata(ResponseMetadata responseMetadata) {
        this.responseMetadata = responseMetadata;
    }

}

When I invoke the transaction it fails due to trying because of the return value with

Thread[fabric-txinvoke:5,5,main] 12:04:38:330 INFO    org.hyperledger.fabric.contract.ContractRouter processRequest                    Got routing:paginatedRichQuery:org.example.FixedAssetContract
Thread[fabric-txinvoke:5,5,main] 12:04:38:345 SEVERE  org.hyperledger.fabric.Logger error                                              nulljava.lang.NullPointerException
        at org.hyperledger.fabric.contract.execution.JSONTransactionSerializer.toBuffer(JSONTransactionSerializer.java:84)
        at org.hyperledger.fabric.contract.execution.impl.ContractExecutionService.convertReturn(ContractExecutionService.java:89)
        at org.hyperledger.fabric.contract.execution.impl.ContractExecutionService.executeRequest(ContractExecutionService.java:67)
        at org.hyperledger.fabric.contract.ContractRouter.processRequest(ContractRouter.java:119)
        at org.hyperledger.fabric.contract.ContractRouter.invoke(ContractRouter.java:130)
        at org.hyperledger.fabric.shim.impl.ChaincodeInvocationTask.call(ChaincodeInvocationTask.java:100)
        at org.hyperledger.fabric.shim.impl.InvocationTaskManager.lambda$newTask$17(InvocationTaskManager.java:265)
        at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)

Move from org.everit.json.schema:1.14.2 to org.everit.json.schema:1.14.4.

There's no way currently to distinguish between 404 (no data found) - possible use-case and 500 (error when trying to get data) when querying data from the private collection. There's a single error handling block that handles all the cases. The details are also not included in the RuntimeException being thrown which may lead to data corruption in the smart contract.
Is there any workaround? Thanks

Once any transaction is invoked, the corresponding transaction serializer will be used for all other transactions as well, regardless of what is set in a @Contract annotation. For example, if we call a method of contract A that uses a default JSONTransactionSerializer, and then call a method of contract B with a custom serializer, then JSONTransactionSerializer will be used in both cases. The reason for this is that within ContractRouter#processRequest creation of an ExecutorService via an ExecutionFactory always returns a singleton instance with one specific transaction serializer:

final SerializerInterface si = serializers.getSerializer(txFn.getRouting().getSerializerName(),
                        Serializer.TARGET.TRANSACTION);
final ExecutionService executor = ExecutionFactory.getInstance().createExecutionService(si);

Thus, the same serializer is used all the time, even though si here can be different.

Its observed that the fabric-chaincode-shim throws ContractException in case of exception in Chaincode however it needs to return the actual cause nested / wrapped inside the chaincode exception.
This is required to fetch the nested exception which is the actual cause in the client sdk adapter when used to run marvin

• What went wrong:
  Execution failed for task ':fabric-chaincode-docker:buildImage'.

Could not build image: The command '/bin/bash -c gradle clean fabric-chaincode-protos:build fabric-chaincode-protos:publishToMavenLocal fabric-chaincode-shim:build fabric-chaincode-shim:publishToMavenLocal -x javadoc -x test -x checkstyleMain -x checkstyleTest -x dependencyCheckAnalyze' returned a non-zero code: 1

any suggestions how to solve this issue?

As per the node chaincode, build into the Java libraries the ability to start the chaincode-as-a-service without needing to write additional code. For reference.. node.js chaincode has fabric-chaincode-node server <options> and fabric-chaincde-node start <options>

i.e. a single main that can take an option to start as a server.
see example code at hyperledger/fabric#2990 (comment)

As a contributor
I want snapshot versions of fabric-chaincode-shim to be published to GitHub Packages on every change
So that I can use development fixes or features before a formal release is published

The release.yml workflow already publishes to GitHub Packages (as well as Maven Central). It would be good for only the GitHub Packages publish to be done on every push.yml workflow. To differentiate from release versions, the Gradle package version used for the push workflow should be of the form x.y.z-SNAPSHOT. This is a standard Maven naming convention.

Although it uses Maven rather than Gradle, the CI pipeline for the fabric-gateway project could be used as a rough guide.

There are currently a couple of tests which are failing randomly(?) which would be good to fix.

The first was introduced with the new OpenTelemetry support recently and is now the most common failure in the interop tests...

2021-10-05T15:47:00.0941330Z OpenTelemetryTracesProviderTest > testTracing() FAILED
2021-10-05T15:47:00.0941865Z     org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
2021-10-05T15:47:00.0942423Z         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
2021-10-05T15:47:00.0943148Z         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
2021-10-05T15:47:00.0943871Z         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2021-10-05T15:47:00.0944667Z         at org.hyperledger.fabric.traces.impl.OpenTelemetryTracesProviderTest.testTracing(OpenTelemetryTracesProviderTest.java:194)
22:41

This test is also flaking often...

2021-10-05T00:19:29.2819784Z org.hyperledger.fabric.contract.ContractRouterTest > testStartingContractRouterWithStartingAChaincodeServer FAILED
2021-10-05T00:19:29.2820502Z     java.lang.AssertionError: 
2021-10-05T00:19:29.2821015Z     Expected: is <SUCCESS>
2021-10-05T00:19:29.2821532Z          but: was <INTERNAL_SERVER_ERROR>
2021-10-05T00:19:29.2822693Z         at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
2021-10-05T00:19:29.2823320Z         at org.junit.Assert.assertThat(Assert.java:956)
2021-10-05T00:19:29.2823924Z         at org.junit.Assert.assertThat(Assert.java:923)
2021-10-05T00:19:29.2824667Z         at org.hyperledger.fabric.contract.ContractRouterTest.testStartingContractRouterWithStartingAChaincodeServer(ContractRouterTest.java:428)

Using 2.2.3LTS
I have the following method

    @Transaction(submit=false)
    public QueryResponse<String> paginatedRichQuery(Context ctx, String queryString, String pagesize, String passedBookmark) {

I invoke paginatedRichQuery with inly 2 parameters rather than 3. The following is output in the chaincode container

Thread[fabric-txinvoke:1,5,main] 11:51:07:448 SEVERE  org.hyperledger.fabric.shim.impl.ChaincodeInvocationTask call                    [2eaadd5f] Invoke failed with error code 500. Sending ERROR
Thread[fabric-txinvoke:5,5,main] 11:51:07:448 SEVERE  org.hyperledger.fabric.Logger error                                              Index 3 out of bounds for length 3java.lang.IndexOutOfBoundsException: Index 3 out of bounds for length 3
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
        at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
        at java.base/java.util.Objects.checkIndex(Objects.java:372)
        at java.base/java.util.ArrayList.get(ArrayList.java:458)
        at org.hyperledger.fabric.contract.execution.impl.ContractExecutionService.convertArgs(ContractExecutionService.java:99)
        at org.hyperledger.fabric.contract.execution.impl.ContractExecutionService.executeRequest(ContractExecutionService.java:57)
        at org.hyperledger.fabric.contract.ContractRouter.processRequest(ContractRouter.java:119)
        at org.hyperledger.fabric.contract.ContractRouter.invoke(ContractRouter.java:130)
        at org.hyperledger.fabric.shim.impl.ChaincodeInvocationTask.call(ChaincodeInvocationTask.java:100)
        at org.hyperledger.fabric.shim.impl.InvocationTaskManager.lambda$newTask$17(InvocationTaskManager.java:265)
        at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)

It looks like the contract api doesn't handle this well and throws an IndexOutOfBoundsException

• Update version numbers in build.gradle files to the required version
• Update test, sample, and docs files to match the new version
• Update the COMPATIBILITY.md file
• Create a new release notes file
• Update the CHANGELOG.md file

Steps to reproduce

I'm looking at version 2.3 but I think the behavior holds for the lastest version.

The following code is based on https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-basic/chaincode-java.

@DataType
public class Sale {
	@Property
	private String guid = "1";

	public Object getPK() {
		return guid;
	}
}


@Contract
public final class AssetTransfer implements ContractInterface {

    @Transaction(intent = Transaction.TYPE.EVALUATE)
    public Sale getSale(final Context ctx) {
        return new Sale();
    }
}

Run the code on the test-network.

What I expect

When I call

peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}'

I expect to see a non-empty output. The output might be {guid:"1"} or {PK:"1"}, I don't know.

Since I already used @Property to annotate a field, I do not expect to see an empty json, i.e., {}.

What actually happened

$ peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}'
{}

Discussion

I looked into fabric-chaincode-java. The constructor of DataTypeDefinitionImpl puts "guid" to this.properties. Then we execute JSONTransactionSerializer.toBuffer(). We will run final JSONObject obj = new JSONObject(new JSONObject(value), propNames); where propNames is ["guid"]. JSONObject outputs nothing in this situation.

It looks like to me that in order for field X to show up in the returned JSON, we have to 1. add @Property to field X; 2. make sure field X has a getter named getX.

To prove if I change to

@DataType
public class Sale {
	@Property
	private String guid = "1";

	public Object getGuid() {
		return guid;
	}
}

I get

$ peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}'
{"guid":"1"}

Suggestion

I feel this issue could be a documentation oversight as @Property didn't mention getters. If maintainers like, I can add something like

/**
 * Field and parameter level annotation defining a property of the class.
 * 
 * When this annotation applied to a field, make sure the field has a 
 * getter.
 ...

Environment: fabric release-2.2
My chaincode named vulnerable is as follows:

1. When I invoke helloworld directly, it gives me responce "helloworld", everything works fine.
2. When I invoke invokeDirectly, it also gives me responce "helloworld".
3. But when I invoke invokeSameContract method, it gives me

and chaincode docker container logging is as follows:

Observation of results above:
(1) the statement System.out.printf("\n%s\n", chaincodeName) works fine.
(2) org.hyperledger.fabric.shim.impl.InvocationStubImpl.invokeChaincode has reached the statement final ByteString response = this.handler.invoke(invokeChaincodeMessage);.

NB: Please note that this issue is in progress and will be updated.

I have decided to amalgamate these all into one list to make things easier for the Hyperledger Fabric team. @denyeart explained that JARs/dependencies with known vulnerabilities are OK to report via GitHub issue. So here we go.