VMware {code} Community
aubale
Contributor
Contributor
Jump to solution

"VerifyError: Error #1053: Illegal Override of CustomProxy...", for plugin in Web Client 6.0

I am having an issue with a plugin developed for 5.1. Works fine with both web client 5.1 and 5.5.

I am trying to deploy the same plugin in web client 6.0 and made following changes with reference of this link for compatibility:

2 Important reminders for your 5.5 plugin to be compatible with Web Client 6.0

-  Changed Web-ContextPath, vsphere-client/plugin-name in MANIFEST.MF

-  Configured two default channels, amf and secure-amf, in services-config.xml and remote-config.xml. :

After these changes, I was able to resolve the "Unable to load resource module..." errors. And I am able to see the icon of my plugin.


I made changes to my own proxy(CustomProxy) class to use ServiceUtil.getDefaultChannelUri(). I have added ServiceUtil code to my plugin instead upgrading from SDK 5.1 to SDK 5.5.2.

Now getting following error upon clicking the plugin icon:

"VerifyError: Error #1053: Illegal Override of CustomProxy...". Please find the screenshot of the flash player error attached.

Could somebody guide to possible cause and resolution for the issue?


Thanks.

Reply
0 Kudos
1 Solution

Accepted Solutions
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

Now I realize the you will not be able to compile this:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null, opId:String = null):void {}

It turns out that the backward compatibility of BaseProxy is broken if one overrides the callService method Smiley Sad . We will take care of fixing this in the next patch or update release.

I can hint you how to fix it for your plugin. And it will work with 6.0. But after we release the patch, your code will break agin. The only thing that you can do at this point is to remove your CustombaseProxy.

So I would recommend the following:

1. Extract the logic that you currently have in utility class, e.g. ProxyArgumentsUtil

   I don't understand why do you keep reference to m_reqMetaData and not create a new instance on each request...

   If you do that, you can have a simple util class with a single static method in it. If you need that reference, then your utility class should be instantiated.

2. All classes that extend CustomBaseProxy should extend directly the BaseProxy

3. Every time you invoke callService, use that ProxyArgumentsUtil to handle your "arguments" parameter

4. Remove the CustomBaseProxy


Apologize for the inconvenience.

View solution in original post

Reply
0 Kudos
10 Replies
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

Are you seeing this error in your local development environment or when you deploy the plugin on the Virtual Appliance?

I have added ServiceUtil code to my plugin instead upgrading from SDK 5.1 to SDK 5.5.2.

Can you elaborate further on this? ServiceUtil was introduced in 5.5.2, but it contains changes in 6.0. You are not supposed to include any SDK code in your plugins...

Reply
0 Kudos
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

I did the following test:

- downloaded SDK 5.1

- modified the MANIFEST.MF, remoting-config.xml and services-config.xml (the change with ServiceUtil is necessary when deploying on real environment)

- compiled global-view sample it against 5.1

- ran the sample against locally running 6.0 client

And I don't see any issues with the custom proxies.

Reply
0 Kudos
vaibhav87
Enthusiast
Enthusiast
Jump to solution

Are you sure you have make all the changes mention in

2 Important reminders for your 5.5 plugin to be compatible with Web Client 6.0

1. Change Web-ContextPath to vsphere-client/plugin-name in MANIFEST.MF

2.Change endpoint class for https : com.vmware.vise.messaging.endpoints.SecureAMFEndpoint

                          http : com.vmware.vise.messaging.endpoints.AMFEndpoint

                                 Add above class entry in MANIFEST.MF, if not available in import list.

3. Add ServiceUtil code to your plugin and use for connection.

with above changes we were able to deploy our plugin to VC 6.0.

Reply
0 Kudos
aubale
Contributor
Contributor
Jump to solution

Thank you for your responses.

Yes, I followed the steps mentioned by vaibhav87.

Peter_Ivanov, I am seeing the error after I deploy the plugin on the Virtual Appliance (vCenter 6.0).

About adding ServiceUtil, I referred following link to add the class:

https://communities.vmware.com/message/2408296


I have a customBaseProxy which extends com.vmware.flexutil.proxies.BaseProxy.

In customBaseProxy, I have a overridden method ”callService”.

I have few proxy classes for different views. For example: GlobalViewProxy which extends the customBaseProxy.

The error is at customBaseProxy. I have attached both customBaseProxy and GlobalViewProxy classes.


I tried renaming the ‘callService’ method without overriding it, but still same error:

public function callServiceCustom(...)

Thanks.

Reply
0 Kudos
laurentsd
VMware Employee
VMware Employee
Jump to solution

The best way for us to reproduce and understand your problem would be for you to modify the GlobalView sample project in a way that shows the same error and attach just the modifications you made. Thanks.

Reply
0 Kudos
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

Thank you for uploading the proxies.

In CustomBaseProxy.as you have problems because you are overriding callService. The problem is that the method signature is changed in BaseProxy in 6.0 release.

Here is the new one:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null, opId:String = null):void {}

Please update the callService signature and try again. You shouldn't have problems any more.

In GlobalViewProxy.as you don't have problems because you are just invoking callService and as you can see from above, the new signature is backward compatible with the old one.

Reply
0 Kudos
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

Now I realize the you will not be able to compile this:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null, opId:String = null):void {}

It turns out that the backward compatibility of BaseProxy is broken if one overrides the callService method Smiley Sad . We will take care of fixing this in the next patch or update release.

I can hint you how to fix it for your plugin. And it will work with 6.0. But after we release the patch, your code will break agin. The only thing that you can do at this point is to remove your CustombaseProxy.

So I would recommend the following:

1. Extract the logic that you currently have in utility class, e.g. ProxyArgumentsUtil

   I don't understand why do you keep reference to m_reqMetaData and not create a new instance on each request...

   If you do that, you can have a simple util class with a single static method in it. If you need that reference, then your utility class should be instantiated.

2. All classes that extend CustomBaseProxy should extend directly the BaseProxy

3. Every time you invoke callService, use that ProxyArgumentsUtil to handle your "arguments" parameter

4. Remove the CustomBaseProxy


Apologize for the inconvenience.

Reply
0 Kudos
aubale
Contributor
Contributor
Jump to solution

Thanks a lot Peter for your response.That really helped.

Yes, I was able to get rid of the VerifyError after following your suggestions of removing CustomBaseProxy and extending my view classes directly from base proxy.

Just one more clarification, my plugin is developed using SDK 5.1 and I am in process of making it work with vCenter 6.0.

You mentioned about these proxy related changes might break after the patch release. Could you please elaborate on that.

Reply
0 Kudos
Peter_Ivanov
VMware Employee
VMware Employee
Jump to solution

Could you please elaborate on that.

Let me try to summarize:

Before 6.0 release BaseProxy#callService looked like this:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null):void

In 6.0 the method signature is:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null, opId:String = null):void


Since the parameter is optional, this has no affect when calling the method with the old set of parameters.

But as you've noticed if you override the callService, Flex does not allow you to change the contract of the method when overriding it.

In the next release we will revert the method back to:

public function callService(methodName:String, arguments:Array, callback:Function = null, callContext:Object = null):void


Hope this make things clearer Smiley Happy

Reply
0 Kudos
aubale
Contributor
Contributor
Jump to solution

Thanks Peter for explaining it in detail.

Reply
0 Kudos