Unexpected exception while assembling one or more items: Problem when evaluating expression “$user.psoFolders.getParentFolderPath($sys.item.guid);” for variable “$path”: no paths returned for 1-101-4112
I also cannot do
if ($user.psoFolders.getParentFolderPath($sys.item.guid)) {
I don’t see any easy way to do this. The assembly service just throws an exception when it can’t find something, and the getParentFolderPath() method just throws that exception back to the user.
When you say “doesn’t have a folderpath”, do you mean that the item is not in any folders?
Also, it might be useful to know what exception is being thrown: this should be in the server log.
2008-05-07 11:51:47,438 ERROR [com.percussion.services.assembly.impl.PSAssemblyService] Failure while processing assembly item
com.percussion.extension.PSExtensionProcessingException: no paths returned for 1-101-3628
at com.percussion.pso.jexl.PSOFolderTools.getParentFolderPath(PSOFolderTools.java:78)
at sun.reflect.GeneratedMethodAccessor640.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:232)
at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:105)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
at org.apache.commons.jexl.parser.ASTJexlScript.value(ASTJexlScript.java:58)
at org.apache.commons.jexl.ScriptImpl.execute(ScriptImpl.java:48)
at com.percussion.utils.jexl.PSJexlEvaluator.evaluate(Unknown Source)
at com.percussion.utils.jexl.PSJexlEvaluator.evaluate(Unknown Source)
at com.percussion.services.assembly.impl.PSAssemblyService.o00000(Unknown Source)
at com.percussion.services.assembly.impl.PSAssemblyService.assemble(Unknown Source)
at com.percussion.services.assembly.impl.PSAssemblyService.processServletRequest(Unknown Source)
at sun.reflect.GeneratedMethodAccessor326.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at $Proxy90.processServletRequest(Unknown Source)
at com.percussion.services.assembly.impl.PSAssemblyServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.percussion.webdav.PSWebDavRequestFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.percussion.servlets.PSSecurityFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Unknown Source)
2008-05-07 11:51:47,453 ERROR [com.percussion.services.assembly.impl.PSAssemblyServlet] Problem assembling item (3628): Unexpected exception while assembling one or more items: Problem when evaluating expression “$user.psoFolders.getParentFolderPath($sys.item.guid);” for variable “$path”: no paths returned for 1-101-3628
I suppose we could change this so that we return NULL instead of throwing an exception. You’d have to check that the value was present before using it.
This change would have some effect on other customers, but I doubt that the impact is serious: anybody who does this today will get an exception. After the change they will die of a null pointer exception.
Will this do it for you? If so, I’ll rebuild it for you.
Not a big fan of null-pointer exception. At least current exception is infromative. In example below, cid 3628 is orphan and it can be “linked” at the backend table.
As it turns out, the two different getParentFolderPath() methods were inconsistent.
getParentFolderPath(IPSGuid) throws an exception when item is not in any folder.
getParentFolderPath(IPSAssemblyItem) returns a null when the item is not in any folder.
Since it’s legal for an item not to be in any folder, I think James is right: if we return a null, the implementer can check the return (with #if) to see if there really is a folder. The only downside is that some existing templates (that today die with a PSExtensionProcessingException) will tommorrow die of a NullPointerException instead, because they don’t check that the folder returned may in fact be null.
If we throw an Exception, everything stops immediately.
I’ve checked this change in, and it will appear in all future toolkits (unless somebody has a very strong argument).
Out of curiosity, how does getParentPath() even hit orphans? I always thought it just traverses the folder tree relationships, which is what orphans don’t have.
It starts from the content item and builds a list of all folder parent relationships. (An item can be in more than one folder), and works upwards from there.
An item which is in no folders has an empty list, which is why the path is null.