java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: Error on line 1 of document : Content is not allowed in prolog. Nested exception: Content is not allowed in prolog.

background

The project uses VMware vSphere to take a snapshot before software upgrade

problem

java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: Error on line 1 of document : Content is not allowed in prolog. Nested exception: Content is not allowed in prolog.

Research
On a personal intuition, it is determined that the other party has upgraded VM Server.(Don’t ask why not to inform)
Then find out which version is now and how to check the version

Starting with vSphere 4.0, information about the supported API versions is contained in an XML file, vimServiceVersions.xml, located on the server (see Service-Versions File (vimServiceVersions.xml)). You can access this file with the URL https://server_hostname/sdk/vimServiceVersions.xml.
ref: https://vdc-repo.vmware.com/vmwb-repository/dcr-public/5c1c7b8c-0d1b-4037-af84-5f43787eb378/fab98b61-56a7-4608-992f-818d3b40e4ae/GUID-75B9897E-551B-4C08-B382-A616A007A07D.html

Service-Versions File (vimServiceVersions.xml)
<?xml version="1.0" encoding="UTF-8" ?>
- <!--    Copyright 2008-2010 VMware, Inc.  All rights reserved. -->
- <namespaces version="1.0">
     - <namespace>
            <name>urn:vim25</name>
            <version>5.0</version>
     - <priorVersions>
          <version>2.5u2</version>
          <version>2.5</version>
       </priorVersions>
     </namespace>
     - <namespace>
          <name>urn:vim2</name>
          <version>2.0</version>
       </namespace>
  </namespaces>

Check it, 7.0.2.0

Will the vijava version used by the client also be updated

As soon as Maven warehouse looks for it, good guy, only this version is the version currently in use.

https://mvnrepository.com/artifact/com.vmware/vijava

Is it possible that this 7. X version is newly upgraded so that vijava.jar is not supported

The key words are determined as: vijava vSphere 7

The official notice is mentioned in the text

HTTP reverse proxy in vSphere 7.0 enforces stricter standard compliance than previous versions. This can lead to pre-existing problems in some third-party libraries that your application uses to make soap calls to vSphere

If you develop vSphere applications that use this class library, or include applications that depend on this class library in the vSphere stack, you may encounter connection problems when these libraries send HTTP requests to vmomi. For example, an HTTP request from the vijava library may take the following form:

POST /sdk HTTP/1.1

SOAPAction

Content-Type: text/xml; charset=utf-8

User-Agent: Java/1.8.0_ 221

The syntax in this example violates the HTTP protocol header field requirement that a colon must be used after a soapaction. Therefore, the request was rejected at execution

Solution: developers who use non compliant libraries in their applications can consider using libraries that follow HTTP standards instead. For example, developers using the AVI Java library can consider using the latest version of the yavi Java library instead

ref: https://docs.vmware.com/cn/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html

Solution:

Replace vijava.jar.jar with yavijava.jar

https://github.com/yavijava/yavijava

Download jar

https://mvnrepository.com/artifact/com.toastcoders/yavijava

Install jar

mvn install:install-file -Dfile=PATH/yavijava-6.0.05.jar -DgroupId=com.toastcoders -DartifactId=yavijava -Dversion=6.0.05 -Dpackaging=jar

Reference jar

<dependency>
    <groupId>com.toastcoders</groupId>
    <artifactId>yavijava</artifactId>
    <version>6.0.05</version>
</dependency>

Similar Posts: