Hazenet
Enthusiast
Enthusiast

Error importing package

Jump to solution

Hi all

I have a customer running vRO (embedded in vRA) version 7.3.x, whom are trying to import a very simple package containing only one workflow.

But they are seeing the below error:

cannot assign instance of java.util.LinkedHashSet to field ch.dunes.model.pkg.impexp.PackageImport.certificates of type java.util.Vector in instance of ch.dunes.model.pkg.impexp.PackageImport

Also see the below screenshot:

2019-05-01_22-16-01.png

Anyone have an idea what is happening here?

I have tested the package can be imported in a vRO (version 7.3.0.5481809) instance that we our self have running, so it does not seem to be something version specific.

0 Kudos
1 Solution

Accepted Solutions
Hazenet
Enthusiast
Enthusiast

The issue have been resolved.

The problem turned out to be a miscommunication.

Our Account Manager team was providing this Package to our customers for some report-generation.

But somewhere in the process, the .package was renamed to .zip

Now vRO Client have no problem importing a package that is actually called .zip instead of .package.

But if the customer gets slightly confused and unzips that .zip file, and then try to import the folder or only parts of the folder, then vRO Client will throw an error similar to the screenshot.

After the customer was explained to just import the original .zip file, everything worked as expected.

View solution in original post

0 Kudos
2 Replies
iiliev
VMware Employee
VMware Employee

Hmm, that's an interesting error. It could be some version incompatible change made in some of the 7.3.x service packs.

A few questions:

  • Could you share this package?
  • Could you ask the customer what is the exact version/build number they are using (for us to try to reproduce the issue internally)
  • Could you collect more info about the error (like full Java stack trace) from vRO log files? Note that there could be error info both in vRO server log file (server.log) and in vRO client log file (vso.log)
0 Kudos
Hazenet
Enthusiast
Enthusiast

The issue have been resolved.

The problem turned out to be a miscommunication.

Our Account Manager team was providing this Package to our customers for some report-generation.

But somewhere in the process, the .package was renamed to .zip

Now vRO Client have no problem importing a package that is actually called .zip instead of .package.

But if the customer gets slightly confused and unzips that .zip file, and then try to import the folder or only parts of the folder, then vRO Client will throw an error similar to the screenshot.

After the customer was explained to just import the original .zip file, everything worked as expected.

0 Kudos