Groovy script fails: unable to resolve class

[Bart Vreeken]

Hi,

Currently our customer is facing a problem when running Groovy scripts from the 'Queue'. Basically, when we run the script manually in the CMS using the Updater Editor, the script runs fine. When the same script is triggered from the queue during re-deployment (in test environment) the script fails:

ERROR Cannot run updater: ...MultipleCompilationErrorsException: startup failed:
updater: 4: unable to resolve class nl.company.cms.utils.OurCustomUtilClass

Groovy script:

The script uses a specific utility class to search&load config property files from the classpath. Both utility class and props are located into the -cms module (plugin) jars. So should be available on the classpath of the CMS war application.

Setup test environment: 

We've separated the Site and CMS wars to run on different tomcat instances. To do this the Site war is deployed with an additional Repository war, so it has all required dependencies like the RepositoryServlet. This strategy is described in http://www.onehippo.org/library/deployment/supported-deployments.html (option 2).

Our observation...

...is that the Groovy script (during redeployment) runs on the Site tomcat instance (probably triggered by the Repository WAR). Therefore, it cannot find the OurCustomUtilClass. In my opinion this is undesired behavior because:

As mentioned in http://www.onehippo.org/library/concepts/update/using-the-updater-editor.html (last paragraph Portability), all libraries packaged with your CMS app should be available to the Groovy script. The error shows that this is not true.
Also, the behavior is inconsistent: on redeploy (running the script from the queue) the script fails. When running the script manually (from the CMS updater editor) the script runs correctly. 
So, my question is: is this a bug? How can we make sure that all groovy scripts are triggered by the CMS instance, always? Any workarounds?

Thanks and regards,

Bart Vreeken

[Unico Hommes]

Not sure to call it a bug, but it is certainly a limitation. There is
currently no way to prevent the site node from picking up the updater
job in the queue. You'll have to factor out the updater helper classes
into a separate module and include them in both cms and site webapps.

--
Unico

>
>
> Thanks and regards,
>
> Bart Vreeken
>

> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.

[Bart Vreeken]

Hi Unico,

I'm afraid we can't factor out this dependency. We simply need a location where we can store these configuration property files (which are loaded by this util class).

So in my opinion it would be really nice if this can be changed.

Me and Dirkjan will investigate possible options and let you know...

regards,

bart