Solved a strange problem with the legacy Portlet.

A strange problem encountered during the creation of the Portlet is that the rft transmission is well performed using Java applications, but in Pluto, the same program does not work, and the prompt is:
No client transport named 'https' found!
Search for the GT official website maillist, found someone mentioned that axis did not read the correct configuration file, copy the config-client.wsdd under the gt4 directory to the WEB-INF/classes. As a result, there is still a problem:
[Http-8080-Processor24] Error delegation. delegationutil-org. Apache. axis. configurationexception: Java. Lang. classnotfoundexception: org. Globus. WSRF. impl. Security. Authorization. clientpropertieshandler
However, this class has been defined in wsrf_core.jar. Why can't this class be found? Does Pluto not search for libraries under the WEB-INF/lib (all the jars under the GT have been copied to this directory, including wsrf_core.jar )? Copy wsrf_core.jar to other shared library directories of Pluto. This problem cannot be solved for a long time and has been put on hold until today. Today, I asked my classmates to help me check the results. After debugging for a long time, no results were returned. However, the wsrf_core.jar file cannot find ORG/Globus/WSRF/impl/security/authorization/clientpropertieshandler. class, but only ORG/Globus/WSRF/impl/security/authentication/clientpropertieshandler. class! Let's look at wsrf_core.jar under gt4/lib, which has this class, and the sizes of these two jar files are different! Suddenly I suddenly realized that the original wsrf_core.jar was an old version or damaged file, so I overwritten it with the new file and reinstalled Pluto, and everything went smoothly.
It seems that in the future, we should not only be skeptical, but also be more careful.