11-06-2014 01:10 AM - edited 03-01-2019 06:20 AM
Hi,
We are trying to port a module which has been tested on UCS Director 5.0 onto version 5.1.
The 5.1 open automation guide suggests the difference from the previous release. I do not understand the second row of Table 1 mentioned in the above link as indicated next.
Introduced the createAccountType() class in place of the getCollectors() class. | Replaced the getCollectors() class with the createAccountType() class. |
We tried adding a method called createAccountType() in the Module class, but the AbstractCloupiaModule super class does not have any such method that requires to be overriden.
Could someone please help as to what code change is expected.
Regards,
Nataraj
11-13-2014 12:36 AM
Hi Nataraj,
In Open Automation 5.1, deprecated the getcollectors() method, to add account and collects the inventory of the account , we have introduced the createAccountType() method in FooModule class. And also you cannot port the module developed in UCSD 5.0 to UCSD 5.1. The library jars in UCSD 5.0 does not support for UCSD 5.1 library jar changes. This is causing "AbstractCloupiaModule super class does not have any such method that requires to be overriden."
11-13-2014 03:58 AM
Hi Logesh,
Thanks for your reply.
Just few details about the the use of the word "porting" from 5.0 to 5.1
No code changes were done. Since the 5.1 open automation guide mentioned about createAccountType(), we posted the earlier question thinking code change is expected.
The module code was compiled against the 5.1 jars. And no compilation errors were reported.
But when the module was deployed, the module failed internally (inventories not getting populated). Investigation shows that the module inventory loading internally fails with NoClassDefFoundError for a third-party jar class listed in the module's feature file. But the jar has been packaged as part of the module and the relative path of the jar is correctly mentioned in the feature file.
Could you please help as to why this may happen. Please note that the same module (3rd party jar, feature file) works correctly on 5.0 UCS Director.
Thanks,
Nataraj
11-13-2014 08:53 AM
Hi Nataraj,
Which 3rd party jar is causing the issue?
Thank you,
Lekha.
11-13-2014 07:25 PM
Hi Lekha,
The 3rd party jar is jersey-client-1.18
On the appliance, the jar is available at the location /opt/infra/inframgr/features/<Module-Folder>/lib
From this location it does not work. The entry in the module feature file is "features/<Module-Folder name>/lib/jersey-client-1.18.jar"
When I place the jar directly under /opt/infra/inframgr/ and modify the /opt/infra/inframgr/run.sh script to include this jar on the classpath, only then the inventories get populated as the REST call to the backend servers succeed.
Thanks,
Nataraj
11-13-2014 08:40 PM
Hi Nataraj,
To assist you further , would it be possible to get to us through Cisco UCSD contact you may have.
This will enable us to work with you directly.
Thank you,
Lekha.
11-13-2014 11:04 PM
Alternately, if you could share your email contact, it will enable quicker resolution of the issue.
Thank you,
Lekha.
11-17-2014 02:14 AM
Hi Lekha,
Due to security policy I will not be able to share my official Id in the forum.
My personal id is subramanian_nataraj@yahoo.com.
You could send any details to this mail id or post in this thread as convenient.
Thanks,
Nataraj
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide