hyperledger / fabric-sdk-java Goto Github PK

newChannel.joinPeer(peer, createPeerOptions().setPeerRoles(EnumSet.of(Peer.PeerRole.ENDORSING_PEER, Peer.PeerRole.LEDGER_QUERY, Peer.PeerRole.CHAINCODE_QUERY, Peer.PeerRole.EVENT_SOURCE)));
17:02:00.735 [main] ERROR o.h.f.sdk.Channel - [joinPeer,896] - Channel{id: 2, name: mychannel} removing peer Peer{ id: 3, name: peer0.org1.example.com, channelName: null, url: grpcs://172.22.110.75:7051} due to exception Getting block time exceeded 5 seconds for channel mychannel
17:02:00.735 [main] ERROR o.h.f.sdk.Channel - [joinPeer,899] - org.hyperledger.fabric.sdk.exception.TransactionException: Getting block time exceeded 5 seconds for channel mychannel
Exception in thread "main" org.hyperledger.fabric.sdk.exception.ProposalException: Getting block time exceeded 5 seconds for channel mychannel
at org.hyperledger.fabric.sdk.Channel.joinPeer(Channel.java:900)
at org.hyperledger.fabric.sdk.Channel.joinPeer(Channel.java:817)
at com.ruoyi.fabric.FrabricSdk.constructChannel(FrabricSdk.java:137)
at com.ruoyi.fabric.FrabricSdk.main(FrabricSdk.java:190)
Caused by: org.hyperledger.fabric.sdk.exception.TransactionException: Getting block time exceeded 5 seconds for channel mychannel
at org.hyperledger.fabric.sdk.Channel.seekBlock(Channel.java:2691)
at org.hyperledger.fabric.sdk.Channel.getGenesisBlock(Channel.java:1855)
at org.hyperledger.fabric.sdk.Channel.joinPeer(Channel.java:859)
... 3 more

Error: Failures:
Error: End2endJavaIT.setup:60->End2endIT.runFabricTest:209->End2endIT.runChannel:791 expected:<[e8e7f5534d3b63dca0a652d16a7d29e4e61d5d4ab579bb0d9e9f23f501b7ac5f]> but was:<[88ed5616e9505389892d2e760d21a3cd61ad233eb1ca54df96a93d9b033c486a]>

The test code needs to be updated to either accurately capture the ordering (possibly a concurrency issue) or, if the implementation does not reliably maintain ordering, not to be sensitive to the ordering.

There is not such thing in the connection profile ref doc. We are only aware of that by walking through your code here .

Since the below news has come up, https://www.wired.com/story/log4j-flaw-hacking-internet/

Could you please let me know by when will the bew version with this issue managed be released?

I would like to know if using fabric-sdk-java v2.1.1 does contain the log4j vulnerability issue(https://www.wired.com/story/log4j-flaw-hacking-internet/) since they have the below dependencies in the main pom.xml:

-

log4j

log4j

${log4j.version}

-

log4j

apache-log4j-extras

${log4j.version}

Please help clarify this.

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.

Hi,

I am using the fabric-gateway-java sdk for my api server connected to hyperledger. When it tries to call below function, seems like some error appear from fabric-sdk-java-2.2.11. Not sure if having compatibility issue with protobuf GeneratedMessageV3. Could you please help me on this ? Should I reduce the version to 2.2.10 ?

#############################################

Network network = gateway.getNetwork("main-channel");

############################################

ERROR LOG

java.lang.NoSuchMethodError: 'boolean com.google.protobuf.GeneratedMessageV3.isStringEmpty(java.lang.Object)'
at org.hyperledger.fabric.protos.msp.Identities$SerializedIdentity.getSerializedSize(Identities.java:237) ~[fabric-sdk-java-2.2.11.jar!/:na]
at com.google.protobuf.AbstractMessageLite.toByteString(AbstractMessageLite.java:58) ~[protobuf-java-3.13.0.jar!/:na]
at org.hyperledger.fabric.sdk.transaction.TransactionContext.(TransactionContext.java:70) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.newTransactionContext(Channel.java:2823) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.newTransactionContext(Channel.java:2819) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.getConfigBlock(Channel.java:907) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.parseConfigBlock(Channel.java:1964) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.loadCACertificates(Channel.java:1801) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.sdk.Channel.initialize(Channel.java:1222) ~[fabric-sdk-java-2.2.11.jar!/:na]
at org.hyperledger.fabric.gateway.impl.NetworkImpl.initializeChannel(NetworkImpl.java:59) ~[fabric-gateway-java-2.2.3.jar!/:na]
at org.hyperledger.fabric.gateway.impl.NetworkImpl.(NetworkImpl.java:50) ~[fabric-gateway-java-2.2.3.jar!/:na]
at org.hyperledger.fabric.gateway.impl.GatewayImpl.getNetwork(GatewayImpl.java:252) ~[fabric-gateway-java-2.2.3.jar!/:na]
at com.intelliwaremy.hyperledger.services.CoreServiceImpl.evaluateTransaction(CoreServiceImpl.java:255) ~[classes!/:0.0.16]
at com.intelliwaremy.hyperledger.controllers.CoreController.evaluateTransaction(CoreController.java:79) ~[classes!/:0.0.16]
.......

We have observed that below ERROR level log is getting printed for every invalid transaction sdk receives and we think that this log should be at INFO level.
Receiving invalid transaction should not be considered as failure case, it is a BAU case.

2021-11-22 12:00:02.254 [pool-6-thread-173] ERROR Channel - Future completed exceptionally: sendTransaction
org.hyperledger.fabric.sdk.exception.TransactionEventException: Received invalid transaction event. Transaction ID b9c18e9a84ef12a4e3b553816c5bf008c4c9469a675631f0f508539d55b851ff status 11
at org.hyperledger.fabric.sdk.Channel$TL.lambda$fire$2(Channel.java:6866) ~[fabric-sdk-java-2.2.3.jar!/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_271]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_271]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_271]

Using low level java sdk 2.2.3.

After some discussion, the issue is that if the low-level fabric-sdk-java Channel.sendTransaction() method is used directly and configured (or defaults) to waiting for transaction commit events, an MVCC_READ_CONFLICT can occur and will be logged as an error in the SDK log. However this is not technically an error as an MVCC_READ_CONFLICT means the transaction is properly invalidated until the world state is read again.

Unfortunately, the logging for the Channel.sendTransaction() method uses the same code path for logging real transaction failures as well as non failures such as MVCC_READ_CONFLICTS.

The request is that a change be made such that actual errors are logged as errors and non errors are logged as info or warning. I believe this would require the code to try and guess the severity from a transaction validation code if one is associated with the error.

We also discussed changing the log level for any errors from Channel.sendTransaction() to warning. However, this would mask real errors in the logs and may affect other users who are scraping the logs for error messages.

The high level SDK uses a different flow so does not have this issue. Obviously though it's work for users to move to that SDK who are already using the low level SDK.

Hello

When the private key is in a non-standard (in my case ECDSA), org.bouncycastle.openssl.PEMParser.readObject() returns an instance of the PEMKeyPair class (it's written in the documentation) and then the org.hyperledger.fabric.sdk.NetworkConfig.getPrivateKeyFromString crashes with an exception:

Caused by: java.lang.ClassCastException: class org.bouncycastle.openssl.PEMKeyPair cannot be cast to class org.bouncycastle.asn1.pkcs.PrivateKeyInfo (org.bouncycastle.openssl.PEMKeyPair and org.bouncycastle.asn1.pkcs.PrivateKeyInfo are in unnamed module of loader 'app')

Screenshot:

Private key like this (values replace to '***'):

I`m use fabric-sdk-java:1.4.x, but this problem not fixed in last sources:
https://github.com/hyperledger/fabric-sdk-java/blob/v2.2.10/src/main/java/org/hyperledger/fabric/sdk/NetworkConfig.java#L945

I'm trying to use the fabric sdk to install a chaincode on my network.
The chaincode gets correctly packaged. I then approve it. which returns some weird thing:

System.out.printf("[approve] chaincodeId: %s, message: %s\n",
                                                lifecycleApproveChaincodeDefinitionForMyOrgProposalResponse
                                                                .getChaincodeID(),
                                                lifecycleApproveChaincodeDefinitionForMyOrgProposalResponse
                                                                .getMessage());

prints:

[approve] chaincodeId: ChaincodeID(_lifecycle::), message: 

with status 200.

Then when I try to commit I get:

[commit] chaincodeId: ChaincodeID(_lifecycle::), message: failed to invoke backing implementation of 'CommitChaincodeDefinition': chaincode definition not agreed to by this org (Org1MSP)

I think there's some kind of issue with the install operation. I'm using version 2.2.2

Here is the extraction from my connection profile:

 "peers":{
    "peer0": {
      "tlsCACerts": {
        "path": "./tls/tlscacerts/tlsca.pem",
        "client": {
          "certfile": "./tls/signcerts/sign.pem",
          "keyfile": "./tls/keystore/key.pem"
        }
      }, 
      "url": "grpcs://xx.xx.xx.xx:7051"
    }
  },

and here is the code:

Path walletDirectory = Paths.get("wallet");
Wallet wallet = Wallets.newFileSystemWallet(walletDirectory);

// Path to a common connection profile describing the network.
Path networkConfigFile = Paths.get("connection_profile.json");

// Configure the gateway connection used to access the network.
Gateway.Builder builder = Gateway.createBuilder()
        .identity(wallet, "admin")
        .networkConfig(networkConfigFile);

// Create a gateway connection
try (Gateway gateway = builder.connect()) {
 

    // Obtain a smart contract deployed on the network.
    Network network = gateway.getNetwork("dev");
    
    Contract contract = network.getContract("fabcar");

} catch (ContractException e) {
    e.printStackTrace();
}

The problem happens at 2 places. The first one is:

 .networkConfig(networkConfigFile);

where in NetworkConfig.java, it will put in props the key 'tlsClientKeyFile'.

if (keyfile != null) {
    props.put("tlsClientKeyFile", keyfile);
}

if (certfile != null) {
    props.put("tlsClientCertFile", certfile);
}

See

This change was introduced since v2.2.4.

Then it goes on to the line:

Network network = gateway.getNetwork("dev");

where, in Endpoint.java, it tries to find 'clientKeyFile' in the properties

if (properties.containsKey("clientKeyFile") || properties.containsKey("clientCertFile")) {

See

Since the property has a different name, the method return null, which results on the peer side returning an error saying the client didn't send the certificate.

Comment about SERVICE_DISCOVERY is incorrect and same with EVENT_SOURCE.

        /**
         * Peer will monitor block events for the channel it belongs to.
         */
        EVENT_SOURCE("eventSource"),

        /**
         * Peer will monitor block events for the channel it belongs to.
         */
        SERVICE_DISCOVERY("serviceDiscovery");

Good habit that check after CtrlC & CtrlV 🔍😁

fanric-java-sdk how to use Taking ledger snapshots and using them to join channels

Due to the security issue of log4j2, update to log4j 2.17.0 -> 2.17.1.

fabric-sdk-java 1.x
fabric-sdk-java 2.x

Reference site: https://logging.apache.org/log4j/2.x/

This sdk inherently sets up large number of threads which I believe is done from a connection pool to the hlf peer. I did not find any documentation to set the same.
Please help me provide the configuration and the steps to implement the same.

I think there's a couple of bugs in the fabric java sdk service discovery code during the sendTransactionProposalToEndorsers loop if it collects insufficient endorsements and has to retry. Specifically, it can rule out layouts and group where there have been valid endorsements as well as those groups that are actually no longer satisfiable.

For example if there were a group with 3 endorsers, of which 2 are required, we received 1 "good" endorsement and 1 "bad" endorsement:

• what we'd expect to happen:
  • the SDLayout.SDGroup.endorsed counter increases by 1.
  • both endorsers are removed from the group (so as to not be re-selected).
  • the group is still flagged as able to be satisfied.
• what actually happens:
  • the endorsed counter stays at 0
    • bug: endorsed = Math.min(required, endorsed++) (the value changed at endorsed++ is never used, i.e. endorsed will always stay at 0 irrespective of required or how many times this line is run)
  • both endorsers are removed as expected.
  • the group is still flagged as not able to be satisfied
    • bug: endorsers.size() >= required; should be endorsers.size() + endorsed >= required; (as we've removed the endorsers already).
    • this also needs the earlier bug to be fixed as well in order to return the correct result.

Obviously, I might be wrong in this, especially as this is code which hasn't changed in a long time yet nobody else has reported this problem that I'm aware of, but I think this is legitimate! Let me know if you want me to attempt a pull request.

You can reproduce by stopping a peer after it has been discovered. If it happens to be selected in the sendTransactionProposalToEndorsers then you should end up in the //still don't have the needed endorsements. section where the bugs are in:

• sdChaindcodeEndorsementCopy.endorsedList(loopGood) for the endorsed counter bug.
• sdChaindcodeEndorsementCopy.ignoreListSDEndorser(loopBad) for the comparator bug.

Obviously it depends on your network topology as to whether this will affect normal usage. I noticed it when running 3 orgs, each with 1 peer, each org's policy requires their peer to endorse, we require a strict majority of org policies, and then simulating a peer failure. I expected txs to still go through as sendTransactionProposalToEndorsers should end up selecting the layout not containing the bad peer eventually, but in reality only 1/3 of the txs work i.e. when it happens to pick the only remaining valid layout first time.

Visit the link https://github.com/hyperledger/fabric-sdk-java
Now click on "Fabric read the docs: Chaincode for Operators" and "Maven repository " and "virtual machines entropy" links as mentioned below
3> virtual machines entropy
http://giovannitorres.me/increasing-entropy-on-virtual-machines.html
we will be redirected to "giovannitorres.me is parked free, courtesy of GoDaddy.com. Get This Domain" error

Currently, security issues have occurred in the version below log4j22.15.0.
In version 2.2 of hyperledger-fabric-sdk java, log4j2 was updated to version 2.15.0. It would be nice to update all versions of hyperledger-fabric-sdk java 1.4.x to log4j2 2.15.0.

Add the missing https://jira.hyperledger.org/browse/FAB-12043 implementation to Java SDK.

Visit the link https://github.com/hyperledger/fabric-sdk-java this .
Now click on "Fabric read the docs: Chaincode for Operators" and "Maven repository " and "virtual machines entropy" links as mentioned below
1> Fabric read the docs: Chaincode for Operators
https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html
we will be redirected to Reads the Docs " SORRY This page does not exist yet. " Error

Visit the link https://github.com/hyperledger/fabric-sdk-java
Now click on "Fabric read the docs: Chaincode for Operators" and "Maven repository " and "virtual machines entropy" links as mentioned below

http://central.maven.org/maven2/org/hyperledger/fabric-sdk-java/fabric-sdk-java/
we will be redirected to below error page
This site can’t be reached
Check if there is a typo in central.maven.org.
If spelling is correct, try running Windows Network Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN

How to reproduce :
1, Clone the fabrice samples,
2, goto fabricsamples\fabcar and start the network.
3, Copy the relevant files and the connection files, fabcar\java- src, pom.xml
4, Run the java client for fabcar from a different machine. ( in may case windows )

Response :
Able to add the Wallets, but getting below grpc comm error.

Steps tried :
Added the org2 peer in connection.yaml file still not resolving..
Added DNS entries, no improvement
Changed to org.hyperledger.fabric.sdk.service_discovery.as_localhost", "false", or true, no improvement.

expecting: Grpcs should take the hostname/fqdn peer name from the configured variable from the docker-compose file.
Any alternate options to override the setting ? How can i override the hostname setting from the grpcs://localhost:9051 ?

An identity for the admin user "admin" already exists in the wallet
An identity for the user "appUser" already exists in the wallet
Oct 28, 2021 10:18:17 AM io.grpc.internal.SerializingExecutor run
SEVERE: Exception while executing runnable io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed@59950e4a    
java.lang.NullPointerException
        at org.hyperledger.fabric.sdk.Channel.getExecutorService(Channel.java:1981)
        at org.hyperledger.fabric.sdk.Peer.getExecutorService(Peer.java:134)
        at org.hyperledger.fabric.sdk.Peer.reconnectPeerEventServiceClient(Peer.java:379)
        at org.hyperledger.fabric.sdk.PeerEventServiceClient$1.onError(PeerEventServiceClient.java:288)
        at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:442)
        at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
        at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
        at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
        at io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:700)
        at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
        at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
        at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
        at io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:399)
        at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:510)
        at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:66)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:630)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$700(ClientCallImpl.java:518)
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:692)        
        at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:681)       
        at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
        at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 34.931 sec <<< FAILURE!
testFabCar(org.example.ClientTest)  Time elapsed: 34.873 sec  <<< ERROR!
org.hyperledger.fabric.gateway.ContractException: No valid proposal responses received. 2 peer error responses: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 2821bb263c90c67c0c4bb8ad94e93a6a34d0f72e8014bd19e8e69686781384d7 
to Peer{ id: 5, name: peer0.org2.example.com:9051, channelName: mychannel, url: grpcs://localhost:9051, mspid: Org2MSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=io exception, cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost/0:0:0:0:0:0:0:1:9051
Caused by: java.net.ConnectException: Connection refused: no further information
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
        at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:327)
        at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:336)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:685)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:745)
}; Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 2821bb263c90c67c0c4bb8ad94e93a6a34d0f72e8014bd19e8e69686781384d7 to Peer{ id: 7, name: peer0.org1.example.com:7051, channelName: mychannel, url: grpcs://localhost:7051, mspid: Org1MSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=io exception, cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost/0:0:0:0:0:0:0:1:7051
Caused by: java.net.ConnectException: Connection refused: no further information
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
        at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:327)
        at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:336)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:685)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:745)
}
        at org.hyperledger.fabric.gateway.impl.TransactionImpl.validatePeerResponses(TransactionImpl.java:196)
        at org.hyperledger.fabric.gateway.impl.TransactionImpl.submit(TransactionImpl.java:93)
        at org.hyperledger.fabric.gateway.impl.ContractImpl.submitTransaction(ContractImpl.java:50)
        at org.example.ClientApp.main(ClientApp.java:53)
        at org.example.ClientTest.testFabCar(ClientTest.java:15)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


Results :

Tests in error:
  testFabCar(org.example.ClientTest): No valid proposal responses received. 2 peer error responses: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 2821bb263c90c67c0c4bb8ad94e93a6a34d0f72e8014bd19e8e69686781384d7 to Peer{ id: 5, name: peer0.org2.example.com:9051, channelName: mychannel, url: grpcs://localhost:9051, mspid: Org2MSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=io exception, cause=io.netty.channel.AbstractChannel$AnnotatedConnectExcept(..) Connection refused: no further information: localhost/0:0:0:0:0:0:0:1:9051

Add headers to all gRPC messages to propagate traces. See the Fabric RFC for reference.

Priority - please update to use log42.17.0

https://logging.apache.org/log4j/2.x/security.html