Abstract class (from plugin) does not appear as a vRO Scripting Object in vso.xml (when using Annotation)

[yatigammanabnd]

In my plugin I have created 2 java classes that extend an abstract class containing common methods that can be used from within vRO.

The abstract class is what has the annotation to compile it into the vso.xml : @VsoObject & @VsoMethod

So what puzzles me is that this object does not actually appear in vRO as a scripting object - which seems to be because when building the vso.xml file, the abstract class in question is not there!

However I can still use the abstract class methods (I know this as these 3 classes -abstract and 2 extended classes- were originally one non-abstract class with the same annotation, and so Actions I created in vRO were using these methods and object as defined by what was in the scripting object browser.)

My Question:

1. Is this a bug with the Annotation? And should defining it in the vso.xml return my abstract object and its methods back in the vRO scripting object browser?
2. If defining it in the vso.xml manually should work, how do I go about building my plugin such that the annotation doesn't kick in and overwrite what I have defined in the vso.xml file?

Hope that makes sense

Background info:

Using VMware vRealize Orchestrator

Version: 7.4.0

Build number: 8071781

[iiliev · Accepted solution]

Hi,

You haven't shown the generated vso.xml and the classes with their annotations, but from your description I think what you see is the normal/expected behavior.

This is not a bug with @VsoObject annotation. This annotation is not inherited. Also, when the packages are scanned during vso.xml generator, there is an explicit check whether the candidate class is concrete (that is, not an interface or an abstract class) and independent (that is, a top-level class or a nested class that can be constructed independently from its enclosing class).

You can still call the base class methods, even if they don't appear in vso.xml, if you haven't set true to  @VsoObject's boolean attribute strict (it has default value false). If this attribute is set to true, only the methods that appear in vso.xml for given scripting object will be available in scripting.

While possible in theory, I don't think that mixing manually created vso.xml content with content generated via annotations is a good idea, so I'd recommend to try first with annotation-only approach, and only if there is some blocking issue, to try the mix.

[yatigammanabnd]

Thank you for your answer, I understand the annotation better now.

So considering that I currently have a method that returns a List<AbstractObject>, which is populated with Concrete extensions of that abstract. Within vRO, if I use this method, the vRO Scripting Object browser displays (e.g.):

Method getListOfObjects()

Return Type: Array

of com.x.y.model.AbstractObject

But while I know what methods are on the AbstractObject, another user would not know as they cannot browse this AbstractObject in the scripting object browser.

Ideally, I'd like it to appear in the scripting object browser (hence the mixed manual/annotation generated vso question - as I know exactly what to put in).

I'm thinking now then that, if I should avoid the mixed vso method if possible, a work around would be to document this AbstractObject elsewhere (e.g. in the @VsoMethod description that provides the list of AbstractObjects so it appears there in the scripting object browser).

So I guess my question is does that seem like a good workaround (from a vRO plugin standards point of view)? And do you have any other workaround ideas?

[yatigammanabnd]

Actually, that (my above idea) was a silly thought.

In the end I made my abstract class concrete (and pushed all the abstract parts of it into a different abstract class), and it is still extended by my other classes still. The annotation now works. yay.