VMware {code} Community
Sinica87
Contributor
Contributor
‎11-04-2021 01:13 AM

Question about packages com.vmware.vise.data.query, com.vmware.vise.usersession

Our local plugin uses packages com.vmware.vise.data.query and com.vmware.vise.usersession. Is there a way to use these packages in remote plugin? Or should we use vim25.jar only?

Reply
0 Kudos
3 Replies
amarinov
VMware Employee
VMware Employee
‎11-17-2021 01:07 AM

Hi @Sinica87,

These packages are not available to remote plugins. You should use the public APIs provided by the vim25.jar.

Thanks,
Aleksandar

Reply
0 Kudos
radoslaw_em
Contributor
Contributor
‎03-14-2022 12:22 PM

Hi @amarinov ,

I see that our local plugin we currently have, makes use of the libs/packages mentioned by @Sinica87. Just to mention a few usages:

  • PropertyProviderAdapter (implemented by our subclasses),
  • DataProviderAdapter (implemented by our subclasses)
  • Provider Adapters are then registered in DataServiceExtensionRegistry classes
  • other classes like userSessionService, VimObjectRefereneService are also injected in our domain classes:
    ...
    <bean     name="ourPropertyProviderImpl"
          class="com.our.package.OurPropertyProviderImpl">
        <constructor-arg ref="userSessionService"/>
        <constructor-arg ref="vimObjectReferenceService"/>
        <constructor-arg ref="dataServiceExtensionRegistry"/>
         <constructor-arg ref="ssoServiceImpl"/>
    </bean>
    ..

I understand that in local plugin these classes are available on vCenter tomcat on which the entire plugin is deployed. It also means, that - for example - a DataService injected in our code comes directly from vCenter's tomcat beans which are already there? It that correct?

In case of the remote plugin we should replace all occurences of com.vmware.vise.* classes with vim25, right?

Correct me if I'm worng but I guess, there is no one-to-one correlation between com.vmware.vise.* and vim25 classes. So is there any migration guide similar to the one for created for frontend api changes but dedicated to backend?

Reply
0 Kudos
amarinov
VMware Employee
VMware Employee
‎03-18-2022 08:10 AM

Hi @radoslaw_em,

I've inlined the answers to your questions in the quote below:

@radoslaw_em wrote:

Hi @amarinov ,

I see that our local plugin we currently have, makes use of the libs/packages mentioned by @Sinica87. Just to mention a few usages:

  • PropertyProviderAdapter (implemented by our subclasses),
  • DataProviderAdapter (implemented by our subclasses)
  • Provider Adapters are then registered in DataServiceExtensionRegistry classes
  • other classes like userSessionService, VimObjectRefereneService are also injected in our domain classes:
    ...
    <bean     name="ourPropertyProviderImpl"
          class="com.our.package.OurPropertyProviderImpl">
        <constructor-arg ref="userSessionService"/>
        <constructor-arg ref="vimObjectReferenceService"/>
        <constructor-arg ref="dataServiceExtensionRegistry"/>
         <constructor-arg ref="ssoServiceImpl"/>
    </bean>
    ..

I understand that in local plugin these classes are available on vCenter tomcat on which the entire plugin is deployed. It also means, that - for example - a DataService injected in our code comes directly from vCenter's tomcat beans which are already there? It that correct?
Correct.

In case of the remote plugin we should replace all occurences of com.vmware.vise.* classes with vim25, right?
Correct.

Correct me if I'm worng but I guess, there is no one-to-one correlation between com.vmware.vise.* and vim25 classes. So is there any migration guide similar to the one for created for frontend api changes but dedicated to backend?
Yes, there is no one-to-one correlation. There is no such migration guide at the moment, you should use the PropertyCollector and other classes provided by vim25, there is an example usage of the PropertyCollector in the remote plugin sample. Please refer to the vSphere Management SDK documentation for further details.

Thanks,
Aleksandar

Reply
0 Kudos