Adding VCS SDK 6 to project also using VCAC 6.2 SDK generating w3 errors...

[rwheadon]

I have a project that needs to operate with VCS and VCAC. VCAC is already working to retrieve machine items and owner identity info, now attempting to attach to VCenter and finding that there are duplicated libs between the two SDKs in their jars. Is VCAC/VCS SDK incompatibility a known / intentional design issue?

By unpacking the jars I have verified that between the two SDK file sets the TransformType class (in path org/w3/_2000/_09/xmldsig_/TransformType.class) occurs 5 times between the 2 SDKs.

I am looking for a workaround that allows both SDKs to be available in one project.

Error Sample:

javax.xml.ws.WebServiceException: Unable to create JAXBContext

  at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:156)

  at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:84)

  at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:234)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.createSEIPortInfo(WSServiceDelegate.java:673)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.addSEI(WSServiceDelegate.java:661)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:313)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:295)

  at javax.xml.ws.Service.getPort(Service.java:119)

  at com.rsa.names._2009._12.product.riat.wsdl.STSService.getSTSServicePort(STSService.java:72)

  at com.vmware.sso.client.samples.AcquireBearerTokenByUserCredentialSample.getToken(AcquireBearerTokenByUserCredentialSample.java:100)

  at com.vmware.vcloud.suite.samples.common.SSOConnection.login(SSOConnection.java:74)

  at com.vmware.vcloud.suite.samples.workflow.VCSJavaScratchsheet.main(VCSJavaScratchsheet.java:58)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:606)

  at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)

Caused by: java.security.PrivilegedActionException: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 46 counts of IllegalAnnotationExceptions

Two classes have the same XML type name "{http://www.w3.org/2000/09/xmldsig#}TransformType". Use @XmlType.name and @XmlType.namespace to assign different names to them.

  this problem is related to the following location:

  at org.w3._2000._09.xmldsig_.TransformType

  at protected java.util.List org.w3._2000._09.xmldsig_.TransformsType.transform

  at org.w3._2000._09.xmldsig_.TransformsType

  at protected org.w3._2000._09.xmldsig_.TransformsType org.w3._2000._09.xmldsig_.ReferenceType.transforms

  at org.w3._2000._09.xmldsig_.ReferenceType

  at public org.w3._2000._09.xmldsig_.ReferenceType org.w3._2000._09.xmldsig_.ObjectFactory.createReferenceType()

  at org.w3._2000._09.xmldsig_.ObjectFactory

  at protected java.util.List org.w3._2000._09.xmldsig_.CanonicalizationMethodType.content

  at org.w3._2000._09.xmldsig_.CanonicalizationMethodType

  at protected org.w3._2000._09.xmldsig_.CanonicalizationMethodType org.w3._2000._09.xmldsig_.SignedInfoType.canonicalizationMethod

  at org.w3._2000._09.xmldsig_.SignedInfoType

  at protected org.w3._2000._09.xmldsig_.SignedInfoType org.w3._2000._09.xmldsig_.SignatureType.signedInfo

  at org.w3._2000._09.xmldsig_.SignatureType

  at protected org.w3._2000._09.xmldsig_.SignatureType oasis.names.tc.saml._2_0.assertion.AssertionType.signature

  at oasis.names.tc.saml._2_0.assertion.AssertionType

  at public oasis.names.tc.saml._2_0.assertion.AssertionType oasis.names.tc.saml._2_0.assertion.ObjectFactory.createAssertionType()

  at oasis.names.tc.saml._2_0.assertion.ObjectFactory

  this problem is related to the following location:

  at org.w3._2000._09.xmldsig.TransformType

  at protected java.util.List org.w3._2000._09.xmldsig.TransformsType.transform

  at org.w3._2000._09.xmldsig.TransformsType

  at protected org.w3._2000._09.xmldsig.TransformsType org.w3._2000._09.xmldsig.ReferenceType.transforms

  at org.w3._2000._09.xmldsig.ReferenceType

  at public org.w3._2000._09.xmldsig.ReferenceType org.w3._2000._09.xmldsig.ObjectFactory.createReferenceType()

  at org.w3._2000._09.xmldsig.ObjectFactory

[rwheadon · Accepted solution]

UPDATE : I was able to put the sdk into its own project and use Maven Shade to relocate the paths of most classes that were proving to be a problem, but I have gotten stuck on the oasis_open paths due to the fact that I can't seem to shade them without blowing up JAXB.

...

<relocations>

  <relocation>

     <pattern>org.w3._2000._09.xmldsig</pattern>

     <shadedPattern>org.w3._2000._09.xmldsig_</shadedPattern>

  </relocation>

  <relocation>

     <pattern>org.w3._2005._08.addressing_</pattern>

     <shadedPattern>org.w3._2005._08.addressing</shadedPattern>

  </relocation>

  <relocation>

     <pattern>com.vmware.sso.client.utils</pattern>

     <shadedPattern>com.vmware.sso.client.utils_</shadedPattern>

  </relocation>

  <relocation>

     <pattern>com.vmware.sso.client.samples</pattern>

     <shadedPattern>com.vmware.sso.client.samples_</shadedPattern>

  </relocation>

  <relocation>

     <pattern>com.vmware.sso.client.wssecurity</pattern>

     <shadedPattern>com.vmware.sso.client.wssecurity_</shadedPattern>

  </relocation>

  <relocation>

     <pattern>com.vmware.sso.client.soaphandlers</pattern>

     <shadedPattern>com.vmware.sso.client.soaphandlers_</shadedPattern>

  </relocation>

</relocations>

...

Current Error:

Exception in thread "main" java.lang.NoSuchMethodError: org.oasis_open.docs.wss._2004._01.oasis_200401_wss_wssecurity_secext_1_0.UsernameTokenType.setPassword(Lorg/oasis_open/docs/wss/_2004/_01/oasis_200401_wss_wssecurity_secext_1_0/PasswordString;)V

  at com.vmware.sso.client.soaphandlers_.UserCredentialHandler.createUsernameToken(UserCredentialHandler.java:61)

I am finding that the classloader is loading org.oasis_open.docs.wss._2004._01.oasis_200401_wss_wssecurity_secext_1_0.UsernameTokenType from com/vmware/cafe/cafe-sdk-client-nodeps/6.2.0/cafe-sdk-client-nodeps-6.2.0.jar and that version of the class does not have the setPassword() method. I'm not really sure why the same version path has two different implementations of UsernameTokenType.class but this is the current stopping point.

Update 2016.08.29 : With tainted SDK code I have gotten these two SDKs to work together. VMWare needs to fix and test their SDKs so that they will both work regardless of Java classpath loader preference unless they would like to accept that vRO, vRA and VCS SDKs are likely NOT going to run together in a single Java project