java.lang.UnsupportedOperationException happens when using Orchestrator's new web client to run workflows, while lagacy client is ok

[panjl3]

We are VMWare's partner and we develop workflows in Orchestrator. Orginally we developed our workflows in the lagacy client and they run always good from vRO 6.0 - 7.3.1 in the lagacy client. Now in the new vRO 7.6 we see a new web client and we are trying to test the workflows in new web client, but we see the following error when start to run some of the workflows, and these workflows can not be run in the new web client(but some other workflows are no error):

When clicked "run" of "Deploy ESXi server with static IP"(see below pic), the page does not go to "run" view, and the page shows "500,OK" in the top. I tried tail -f  /var/lib/vco/app-server/logs/server.log, and when clicking "run" button, it printed the following error:

2019-05-09 08:25:31.145+0000 [http-nio-0.0.0.0-8280-exec-1] ERROR {} [[restServlet]] Servlet.service() for servlet [restServlet] in context with path [/vco] threw exception [Request processing failed; nested exception is java.lang.UnsupportedOperationException] with root cause

java.lang.UnsupportedOperationException

  at com.vmware.o11n.web.form.model.adapter.expressions.FormValueFactory.createNegatedValue(FormValueFactory.java:72)

  at com.vmware.o11n.web.form.model.adapter.FormAdapter$FormBuilderPresentationVisitor.visit(FormAdapter.java:195)

  at ch.dunes.model.presentation.PresentationParameter.accept(PresentationParameter.java:234)

  at ch.dunes.model.presentation.PresentationStep.accept(PresentationStep.java:38)

  at ch.dunes.model.presentation.ParameterPresentation.accept(ParameterPresentation.java:227)

  at com.vmware.o11n.web.form.model.adapter.FormAdapter.adapt(FormAdapter.java:70)

  at com.vmware.o11n.web.form.service.FormService.createInputForm(FormService.java:126)

  at com.vmware.o11n.web.form.service.FormService.getLegacyInputForm(FormService.java:80)

  at com.vmware.o11n.web.form.service.FormService.getForm(FormService.java:55)

  at com.vmware.o11n.web.form.FormController.get(FormController.java:84)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:498)

  at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)

  at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:133)

  at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97)

  at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:849)

  at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:760)

  at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)

  at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)

  at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)

  at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)

  at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)

  at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)

  at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)

  at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at com.vmware.o11n.web.Slf4jRequestLoggingFilter.doFilterInternal(Slf4jRequestLoggingFilter.java:50)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at com.vmware.o11n.web.SlashAppendingFilter.doFilterInternal(SlashAppendingFilter.java:25)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at com.vmware.o11n.json.DefaultJsonVersionHeaderFilter.doFilter(DefaultJsonVersionHeaderFilter.java:95)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at com.vmware.o11n.web.cluster.RestActiveNodeFilter.doFilter(RestActiveNodeFilter.java:63)

  at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:347)

  at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:263)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)

  at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)

  at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:114)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:170)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at com.vmware.o11n.web.auth.http.TokenAuthenticationFilter.doFilter(TokenAuthenticationFilter.java:104)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)

  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)

  at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)

  at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)

  at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)

  at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:347)

  at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:263)

  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)

  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)

  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610)

  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)

  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)

  at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:679)

  at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)

  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)

  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)

  at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)

  at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

  at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)

  at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)

  at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

  at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

  at java.lang.Thread.run(Thread.java:748)

All the workflows in lagacy client of vRO 7.6 are able to be run with no errors. And strangely, in new web client , "Deploy ESXi server with static IP" workflow can not be run with the above error, but "Deploy ESXi server" can be run with no error.  The two workflows are very similar(the only difference is one  deploys ESXi with static ip and one deploys with DHCP), and I have no idea why one can be run in web client but the other can't:

Deploy ESXi server with static IP:

Deploy ESXi server:

The only action that differ in the two workflows:

deployOSStatic:

deployOS:

Is the new web client backward-compatable to workflows developed in lagacy client? Or what modificatons we need to do to support new web client?

Looking forward to your help for this urgent issue. Thanks in advance!

[iiliev]

The legacy client and the new client use a different presentation libraries and different presentation constraint language. The compatibility is not 100%.

In your case, it seems to be an issue with a presentation property about visibility of some field (at least it looks like so from the stack trace). If possible, could you export and attach the workflow to check what exactly in this presentation property is not working?

[panjl3]

Thank you iiliev   Attached exported workflows. "Deploy ESXi server with static IP"(this one can not be run in new web client), and "Deploy ESXi server"(this one can be run in new web client) FYI.

[panjl3]

The "Deploy ESXi server with static IP.workflow" was corrupted in my last comment, re-attach it here.

[iiliev]

Attempt to download the attached file fails with 'file incomplete' error.

[panjl3]

Attached again. iiliev​

[panjl3]

shorten the workflow name to try

[panjl3]

It seems the originally attached "Deploy ESXi server with static IP.workflow", the name was two long, then the file became incomplete. I shorten its name, please download the newly attached staticip.workflow. Thank you.

[iiliev]

The presentation property 'Hide parameter input' of the input parameter isVLAN seems incorrect/corrupted. Which vRO editor have you used to create/edit this workflow?

[BernhardSie]

We had the same problem using the new HTML5 webclient. After a time consuming "trial and error" phase (deleting input parameters step by step and so on) the problem was gone when an input parameter using presentation property "Hide parameter input" was deleted.

Corresponding line in the xml file of the workflow: '<p-qual kind="static" name="notVisible" type="boolean" ><![CDATA[true]]></p-qual>'

So our idea was to put the value "true" explicitly into the value field of that property and the problem was gone:

The line in the xml file of the workflow changed to '<p-qual kind="ognl" name="notVisible" type="boolean" ><![CDATA[true]]></p-qual>'

May be it's a bug in the different presentation libraries and/or different presentation constraint language used in new client.

[panjl3]

Hi IIian,

Thank you! The workflow was originally created and edited by vRO's lagacy client editor of vRO 6.0, and the workflow may be modified in vRO 7.x, all in lagacy client's editor. Would the issue be gone If we delete the "Hide parameter input' property and re-added it using the new web client's editor? Or we need to use BernhardSie's workaround that we need to put the value "true" explicitly into the value field?

[panjl3]

Thank you very much BernhardSie​! We consider to try your workaround!

[iiliev]

'Hide parameter input' and 'Show parameter input' presentation properties have a value that is evaluated at runtime, and if the evaluated value is true, the corresponding property is considered enabled.

In your case, if you want to unconditionally hide the field, you can edit the presentation and either put a value true or put an expression which, when evaluated, will return true.

Arguably, the presentation code could be made more robust and assume default value true if no value is provided for these properties, as it is likely that the user would want to hide the field if you place property 'Hide parameter input' so value true will be a sane default value in this case.

[yatigammanabnd]

I might be a bit late to this - but I don't see any updates in vRO 7.6.

I think that would be the appropriate thing to do (vRO default to hide instead of blowing up) for the visibility case as many plugins have been developed against the legacy client and they now won't work without update to the workflows.

Which is a bit annoying as any html5 client interface could just make the assumption you state above and not make workflow/plugin developers have to do the extra work to make the workflows backwards compatible

Also, iiliev ​, as I haven't managed to get vRO 8.x up and running yet, do you know if that still accepts the xml defined workflows still, or is it all json based now? (Just discovered it does accept xml - see update below)

(I found another related post, but no answer to that question)

UPDATE

I just spun up a vRO 8.0, and

exported the non-working workflow (via legacy client) from vRO 7.6 and it does work in vRO 8.0

exported the non-working workflow (via legacy client) from vRO 7.4 and it does work in vRO 8.0

I also tried the fix mentioned in this thread, and that also works in vRO 8.0 (having a true value entered in). So overall, this workflow issue isn't a problem for vRO 8.0 it seems.