hyperledger / fabric-chaincode-java Goto Github PK
View Code? Open in Web Editor NEWHyperledger Fabric Contract and Chaincode implementation for Java
Home Page: https://hyperledger.github.io/fabric-chaincode-java/
License: Apache License 2.0
Hyperledger Fabric Contract and Chaincode implementation for Java
Home Page: https://hyperledger.github.io/fabric-chaincode-java/
License: Apache License 2.0
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
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.
@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:
and
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
Name | Found in Code | CVEs | Due Date | Status |
---|---|---|---|---|
bcprov-jdk15on-1.62.jar | https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-shim/build.gradle#L46 | https://nvd.nist.gov/vuln/detail/CVE-2019-17359, https://nvd.nist.gov/vuln/detail/CVE-2020-26939, https://nvd.nist.gov/vuln/detail/CVE-2023-33201, https://nvd.nist.gov/vuln/detail/CVE-2020-15522 | Aug 21, 2023 | Addressed by #310 โ |
json-20220320.jar | Transitive dependency from fabric-chaincode-shim , which is imported here: https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-integration-test/build.gradle#L4, and then json-20220320.jar is imported here: https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-shim/build.gradle#L49 |
https://nvd.nist.gov/vuln/detail/CVE-2022-45688 | Aug 21, 2023 | Addressed by #310 โ |
guava-26.0-android.jar, guava-31.0.1-jre.jar | Transitive dependency, in fabric-chaincode-integration-test (https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-integration-test/build.gradle#L4) this time the dependency is on fabric-chaincode-shim : https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-shim/build.gradle#L44C5-L44C5. Shim is dependent on org.hyperledger.fabric.fabric-protos v0.2.0, which is dependent on a vulnerable version of Guava: https://central.sonatype.com/artifact/org.hyperledger.fabric/fabric-protos/0.2.0/overview. |
https://nvd.nist.gov/vuln/detail/CVE-2023-2976, https://nvd.nist.gov/vuln/detail/CVE-2020-8908 | Oct 10, 2023 | Fixed in user-facing code in #314; examples still point to old shim |
json-20180813.jar | Direct dependency here: https://github.com/hyperledger/fabric-chaincode-java/blob/main/fabric-chaincode-integration-test/build.gradle#L4 | https://nvd.nist.gov/vuln/detail/CVE-2022-45688 | Aug 21, 2023 | Fixed in https://github.com/hyperledger/fabric-chaincode-java/pull/314/files โ |
protobuf-java-3.20.1.jar | Direct dependency here:
, but ALSO,
includes io.opentelemetry:opentelemetry-proto at 1.6.0-alpha, which includes protobuf-java at 3.20.1 as shown here: https://mvnrepository.com/artifact/io.opentelemetry/opentelemetry-proto/1.6.0-alpha. and ALSO, shim includes grpc-protobuf at v1.46, as seen here
which includes protobuf-java at v3.20.1 as shown here: https://mvnrepository.com/artifact/io.grpc/grpc-protobuf/1.46.0, and also includes fabric-protos at v0.2.0 as shown here:
and fabric-protos at v0.2.0 includes protobuf-java at v3.20.1 as shown here: https://mvnrepository.com/artifact/org.hyperledger.fabric/fabric-protos/0.2.0 ... AND ALSO I also see a link from fabric-chaincode-java in several examples that go to fabric-protos v0.1.3, which includes protobuf-java at v3.19.4 -- example
and second example |
https://nvd.nist.gov/vuln/detail/CVE-2022-3509, https://nvd.nist.gov/vuln/detail/CVE-2022-3510, https://nvd.nist.gov/vuln/detail/CVE-2022-3171 | Oct 20, 2023 | #310 definitely helps. Moved the direct dependency to v3.19.6, which is not vulnerable. It also moved io.grpc.grpc-protobuf to v1.45.4, which uses protobuf-java v3.19.6. However, this change does not address the dependency on io.opentelemetry:opentelemetry-proto at 1.6.0-alpha, or the dependency on fabric-protos at v0.2.0. |
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
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
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.
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., {}
.
$ peer chaincode query -C mychannel -n basic -c '{"Args":["getSale"]}'
{}
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"}
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:
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.
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.