Add Java example to chaincode as external service documentation

[denyeart]

Per stackoverflow post https://stackoverflow.com/questions/69115892/hyperledger-fabric-java-chaincode-timeout-expired-while-starting-chaincode  , it appears Java chaincode is missing from chaincode as an external service doc topic:
https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html#writing-chaincode-to-run-as-an-external-service

[x-shadow-man]

@denyeart i wanna take this issue.

[indranil32]

@denyeart Do we have an example for "chaincode as external service" in fabric-samples?

[lehors]

@denyeart Do we have an example for "chaincode as external service" in fabric-samples?

Yes, we do. Check asset-transfer-basic/chaincode-external

[Sunxiai51]

@denyeart Do we have an example for "chaincode as external service" in fabric-samples?

Yes, we do. Check asset-transfer-basic/chaincode-external

I cannot find Java external chaincode example in asset-transfer-basic/chaincode-external, just find a demo in fabric-contract-example-external. I try to implement it but failed, chaincode server can start and register chaincode to peer successfully, but the invoke of contract method from peer always be timeout.

Is that example unavaliable? Where can I find available example?

[jkneubuh]

Thanks @x-shadow-man and @Sunxiai51 for moving this forward!

Here's a project that demonstrates how to set up the NettyChaincodeServer to receive the grpc handshake when launching a Java chaincode process as a service: https://github.com/hyperledgendary/contract-as-a-service/tree/main/java-contract

ContractBootstrap.java looks like it is setting up the ChaincodeServer correctly. I was able to launch a chaincode with the bootstrap and receive requests from a peer, which is a good sign.

Also, we recently released a new Fabric Test Network for Kubernetes, which includes the configuration of external builders by default. Using the new test-network-k8s, it's also possible to run Fabric and chaincode servers on a development workstation - for instance, attached to a debugger in Eclipse/IntelliJ/etc.

[Nanra]

Thanks @jkneubuh for your information on the Java Chaincode project demonstration.
Btw in this official documentation Chaincode as External Service states the chain code it as an external service it is only supported by Go and NodeJs. I think it will be a bit confusing for those trying to implement it with Java.

[jkneubuh]

Hi @Nanra I agree : the documentation is both confusing and wrong. One great aspect of using the external Docker build process (and chaincode-as-a-service) is that we can write smart contracts in any language, rather than the limited set supported by the internal chaincode compiler.

To fix this issue I think the following items need to be addressed:

• Add a reference sample / external chaincode project for asset-transfer-basic, highlighting the use of the NettyChaincodeServer and main entry point.

• I checked yesterday that the asset-transfer-basic/chaincode-java smart contract will receive messages through the NettyChaincodeServer, but did not actually build a Docker image to verify that the Dockerfile, gradle build, etc. is set up correctly. (There may be some additional work necessary to set up the project based on the example in the hyperledgendary git.)

• Update the Fabric docs to include both a small Java snippet for both the Netty grpc router and a pointer to the basic asset transfer example. (And update the statement that Fabric only supports Go and Node - wrong!)

Maybe one last feature request on the Java front ... If we are going to build a reference sample for a Java chaincode, let's get the logging correct! Please could you update the code in a couple of places to use an SLF4J Logger, instead of System.out, and include a logback provider in the sample? This is not just a convenience for the smart contract programmers - when running the endpoints in a production context it will be very useful to direct the chaincode logging output to a log aggregator. This is MUCH easier when the routines are sending output to an SLF4J category.

[jkneubuh]

Additional confirmation that it's "too hard" to get started with a Java Chaincode-as-a-Service smart contract:

• https://stackoverflow.com/questions/69613730/hyperledger-fabric-invoke-java-chaincodeas-a-external-service-timeout/69661439#69661439

[Sunxiai51]

@jkneubuh Thanks for your reply.

I found the reason why the invoke of contract method from peer always be timeout, and I try to fix it in hyperledger/fabric-chaincode-java#207

By the way, that question is asked by me. : )

[jkneubuh]

The specific issue of the timeout can be addressed by PR #207.

But in the general case, this opens a couple of questions:

• Why run Java8/11 in mixed mode? If we provide a sample template / reference example for Java Chaincode, it needs to be consistent with respect to the JVM bundled into the docker container. The project template should have clear expectations for javac/java revisions, and just do "the right thing" if end-users copy it verbatim when setting up a new project.

• What went wrong with the peer/chaincode endpoint communication that led to a timeout? This doesn't seem correct. As an app developer writing a chaincode, if an Exception is thrown it should somehow be marshaled up and reported in the peer. Likewise if an Error or unchecked Throwable is sent out of a method, it also MUST be reported. We don't necessarily need to reconstruct the full stack context, but timing out is not good.

@bestbeforetoday - Mark is this related to some of your recent work around exception marshaling within the Gateway SDKs? @Sunxiai51 are you running with fabric 2.3.2 or the new 2.4.0-beta images?

[Sunxiai51]

@jkneubuh Here is my experiences:

• run chaincode with shim 2.3.1 or 2.2.3 on Java8, exception occurs
• run chaincode with shim 2.2.3 on Java9, it works well
• run chaincode with shim which re-built (added type cast) base on 2.2.3, it works well on Java8

I haven't tried the 2.4.0-beta yet.

And I think more important than improving compatibility is to supplement documents with usage and restrictions, hope the documentation will be improved as soon as possible.

[mbwhite]

Hello.. sorry I'm late to this issue.

For reference here are some examples of how to use the chaincode-as-a-service for different langauges. I would like to have some of the 'boilerplate' main code pushed into the main repos. (see Java chaincode issue hyperledger/fabric-chaincode-java#208)

Example code at
#2990 (comment)

(Also see https://github.com/hyperledgendary/contract-as-a-service, that I've seen listed above)

@Sunxiai51 thanks for those testing.. however Java 11 is the minimum support level for any release post Fabric 1.4 (https://github.com/hyperledger/fabric-chaincode-java/blob/main/COMPATIBILITY.md)

[Xingxingyeyouxinshi]

Can anyone share the whole steps of debugging a Java contract through test-netwok-k8s in the IDE(eg.IDEA), or debuging a custom Java chain code ?

Anyone help?Can anyone share the whole steps of debugging a Java contract through test-netwok-k8s in the IDE(eg.IDEA), or debuging a custom Java chain code ?

Anyone help?

[Xingxingyeyouxinshi]

@Sunxiai51
can you share the whole process of building a Java chaincode debugging environment through test-network-k8s?

[mbwhite]

All - @Xingxingyeyouxinshi raised an issue here, that I've grabbed as I've got some material in preparation for this.
hyperledger/fabric-samples#548

There's a question of where to be put the example code - if you've a moment please look at that issue and let me know your thoughts.

[Xingxingyeyouxinshi]

@mbwhite I recorded my thoughts a few days ago, look forward to your reply.

[TrishamBP]

Hi, can the chaincode be written in solidity and deployed? If no will future fabric versions support it?

[jkneubuh]

@denyeart can you assign this ticket to me? I'll pick it up.

[lehors]

Hi, can the chaincode be written in solidity and deployed? If no will future fabric versions support it?

@TrishamBP Hi, we actually had support for this and it was abandoned due to lack of interest. You can find it in the following archived repo: https://github.com/hyperledger/fabric-chaincode-evm
Note that it was functioning but I haven't tried it in a long time so I don't know whether it still works.

[krisstern]

@jkneubuh Are you still working on the issue? If you are not I would like to pick it up and finish it. Please let me know.

[jkneubuh]

Hi @krisstern -

It's hard to say this is "finished" but there was some progress on the Java sample running "CCaaS" over at https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-basic/chaincode-java. If you want to help pick up and carry this over the finish line, it will be much appreciated!

• The Java code has been structured to run either in CCaaS mode or with the traditional handshake.
• The Dockerfile will build an image suitable for running with CCaaS
• The guide includes instructions for running CCaaS on both the Kubernetes test network and Compose network.

In general, "it works" but I'm not sure why I didn't hit the close button on the issue. I think the java sample in current form does an OK job of deploying and running in CCaaS, but it still feels like it needs some guidance to really work well. I don't think this is a code issue with the sample - It's indicative of larger issues of how and where CCaaS fits in to Fabric.

The setup for CCaaS is hard to document, as it requires mixing the lifecycle of the chaincode package with the management of the CC services running "somewhere." In practice what we have been finding is that CCaaS is a great technique, but only in the context of using it as a mechanism to run step-level debugging of chaincode. One of the big challenges here is that we don't have ONE good reference model for deployment with containers that makes working with CCaaS straightforward.

One approach would be to simplify the Java example, cutting out all of the high-level guidance on test/debugging, and just provide a sample of bundling a contract as a Docker container that can run in either CCaaS or traditional mode. I think that would be enough to close this sample as "done," although it opens the need / opportunity to describe step-debugging in some other context.

Before chipping into this issue - maybe consider and review the overall approach to debugging chaincode and deploying container-based contracts? There are some much better patterns that have emerged through the use of the Kubernetes Chaincode Builder and Full Stack Application Development Guide.

(BTW there is an effort in the works to relay the full-stack-asset-transfer guide up to fabric-samples as a reference for building and debugging chaincode.)

[krisstern]

@jkneubuh Sounds like a good idea, let me read up and see where are the gaps I can fill to try and tackle this issue. Thanks for the very detailed response and the tips!