Web Script format 'xlsx' is not registered [solved]

[corstad]

Yesterday we upgraded from Alfresco 3.1 bundled within Adobe Livecycle running on JBoss installed using Adobe's lc_turnkey option to Alfresco 3.4.c Community Edition running on Tomcat 6.0.32. One of the issues that has surfaced in the migration is that a Java backed web script that generates a spreadsheet in the newer .xlsx format for download generates the following exception when requested from IE7, Chrome and Safari clients. But works perfectly when called from a Firefox client.

ERROR AbstractRuntime Exception from executeScript - redirecting to status template error: 02040002 Web Script format 'xlsx' is not registered
org.springframework.extensions.webscripts.WebScriptException: 02040002 Web Script format 'xlsx' is not registered
   at org.springframework.extensions.webscripts.DeclarativeWebScript.execute(DeclarativeWebScript.java:58)
   at org.alfresco.repo.web.scripts.RepositoryContainer$2.execute(RepositoryContainer.java:383)
   at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:381)
   at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecute(RepositoryContainer.java:436)
   at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecuteAs(RepositoryContainer.java:466)
   at org.alfresco.repo.web.scripts.RepositoryContainer.executeScript(RepositoryContainer.java:304)
   at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:333)
   at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:189)
   at org.springframework.extensions.webscripts.servlet.WebScriptServlet.service(WebScriptServlet.java:118)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:58)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:864)
   at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
   at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1665)
   at java.lang.Thread.run(Thread.java:662)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The web script desc file (contentlist.get.desc.xml)

<webscript>
<shortname>list folder</shortname>
<description>
   Datasite list the contents of a folder.
   The default format is JSON. To export to a spreadsheet add a dot xlsx (.xlsx)
   to the end of the URL. ie. /projects/{projectUuid}/content/{nodeUuid}.xlsx
</description>
<url>/projects/{projectUuid}/content/{nodeUuid}</url>
<authentication>user</authentication>
<format default="json">extension</format>
</webscript>‍‍‍‍‍‍‍‍‍‍‍‍

The strange item in the exception stack trace is the first line references DeclarativeWebScript.execute method. Our web script doesn't extend DeclarativeWebScript, it actually extends AbstractWebScript. Not sure why DeclarativeWebScript is involved at this point.

Any idea what we need to change in our configuration or code to restore this functionality?

Thanks,

Cully.

[corstad]

It was a problem with the construction of the URI the client side pointing to a non-existent destination. Firefox code would fix the broken code, the others did not.