VMware {code} Community
rszymczak
Hot Shot
Hot Shot

Inner workings of VSOFactoryClient - or using the ResourceElements

Hi There,


developing a vCO plugin I wanted to use the ResourceElement way of doing. Unfortunately those classes are not very well - not to say not at all - documented. Soo I was hoping to get some support here.

Okay, what I'm trying to figure out are the inner workings of ch.dunes.model.client.VSOFactoryClient and in special what the Deprecated "connect" method are doing (and, since it's deprecated, what's the new way of doing it). So far, I know that the VSOFactoryClient instance will be used for all ongoing ResourceElement operations (insertResourceElement, getRootResourceElementCategorys and so on).

However, it is unclear to me why I would need to submit the VCO Hostname/IP and a ch.dunes.util.UserToken to it. Isn't the PluginFactory supposed to handle user-sessions?

So, the questions I have are as follows:

1. How is VSOFactoryClient related to PluginFactory (to be more precise, the AbstractSpringPluginFactory implementation)

2. If using the AbstractSpringPluginFactory and AbstractSpringPluginAdaptor implementations, effectively there is no IPluginFactory createPluginFactory method which could provide the input parameters (username / password) needed for the VSOFactoryClient.connect method, so how and where (within the Adapter or the Factory?) to instantiate the VSOFactoryClient. From the formal definitions, since the Factory should handle sessions, it seems that the factory should handle that. However, it seems that every time ResourceElement is used, it's instantiated within the Adapter.

3. What about one session for all user scenarios? What is the UserToken used for if not sessions?

4. Why do we need to provide a vCO IP at all? Isn't there a fallback to localhost?

5. Using the AbstractSpringPluginAdaptor implementation, the AbstractSpringPluginFactory  is never explicitly called within the Adapter. However, it seems that the DAO used has to be instanciated there and added to the OBJECTManager class so the OBJECTManager may handle any object requests. Since I'm not sure how adding the factory to the OBJECTManager is handled my guesses are limited here. However, a quick & dirty example how to do DAO using AbstractSpringPluginAdaptor  and AbstractSpringPluginFactory   as well as a small explanaition how factory and dao will be sent to the OBJECTManager would be great

// EDIT

6. despite everything else - the core of why i'm looking for answers is because I want to implement ResourceElements using a Spring-Only Plugin version (thus - VSOFactoryClient, which seems to handle the ResourceElements, is not useable the "normal" way). Soo: what classes would handle ResourceElement in such a case?


Hope you guys can help me


Greets


Robert

0 Kudos
1 Reply
iiliev
VMware Employee
VMware Employee



Hi Robert,


VSOFactoryClient and IPluginFactory hierarchy are not related. The former is an endpoint to vCO server private API, the latter - part of public SDK/API.


Being a part of vCO private API, it is not recommended to create and manage new factory clients in the consumer code. Instead, if really needed, you may try to get access to already existing factory. Unfortunately, there is no supported/recommended way for getting such access. Few of our plug-ins that need such access use some hacks to get it, but this is totally unsupported and not guaranteed to work with future vCO releases.


I'm not very familiar with the implementation of plug-in SDK so I cannot comment on your questions about AbstractSpringPluginAdaptor/Factory.


-Ilian

0 Kudos