[MGNLGROOVY-236] Magnolia doesn't reload module when updating a Groovy script belonging to it Created: 28/Jan/22  Updated: 23/Oct/23

Status: Open
Project: Magnolia Groovy Module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Medium
Reporter: Niclas Horstad Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Magnolia DX Core 6.2.13


Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: DevX Bucket
Team: DeveloperX

 Description   

Steps to reproduce

  • Write a custom Command in a Groovy script.

Example:

package example.commands;

import info.magnolia.commands.impl.BaseRepositoryCommand;
import info.magnolia.context.Context;

public class ExampleCustomCommand extends BaseRepositoryCommand {
    @Override
    public boolean execute(Context ctx) {
        println "TEST";
        return true;
    }
}
  • Add the Command to an existing module, e.g. "publishing-core" under a new Catalog with any name.
  • Whitelist the Command in the "rest-services" module to enable access via the Commands v2 API.
  • Test your script via the Commands v2 API endpoint to ensure it works.
  • Update your Groovy script (e.g. make it print something else).
  • Test your script again via the Commands v2 API endpoint.

 

Expected results

The saved changes to the Groovy script are reflected when executing the custom Command via the Commands v2 API endpoint.

Actual results

The OLD version of the Groovy script is executed. The saved changes are not reflected in the Groovy script.

Workaround

In the "Config" app, rename the Command to something arbitrary inside the module's "commands" node, and then rename it back to the original name.

This forces the module to reload. The saved changes in the Groovy script are now reflected in the Commands v2 API endpoint.

Comments

Magnolia usually does a pretty good job of updating itself so that changes to files are reflected immediately - especially with light modules.

This is the first time Magnolia didn't behave as expected and it unfortunately wasted so much of my time this week. Please get it looked at.

BR,

Niclas Horstad



 Comments   
Comment by Richard Gange [ 31/Oct/22 ]

This is an example of a Groovy class (not a script) so there is a slight distinction here. The way Groovy works is to interpret the class on the fly. This is what makes it so flexible. The trade off is the first time you execute the Groovy class it's slightly slower. Afterwards all executions of the class should be on par with the equivalent code in Java.

The OLD version of the Groovy script is executed. The saved changes are not reflected in the Groovy script.

While you can replace most classes in the system with Groovy classes it would be really challenging to know if a Groovy class has been used somewhere in the system. So this is why if you make a change to the class you need to go back and reload the configuration. You should not have to rename anything. Just by clicking in the value of the class property should be enough to make the module reload.

One thing to keep in mind for the long term is we are moving away from configuration in JCR. Configuration by file is now the preferred approach. Commands have not yet been ported to config by file but I would expect it to come at some point.

I am sorry you spent so much time tracking down the issue but tbh I don't believe there is a whole lot of users replacing classes with Groovy and to say we should create a mechanism to scan the entire configuration for the off chance a groovy class might be used seems like a lot. Perhaps we could be a little better in our documentation of the groovy module but it does mention that the class property value triggers the reloading.

You can use this command to replace a similar Java command at runtime. Or you can edit it and have it compiled and replaced on the fly (a kind of class hot deploy). This relies on the Magnolia observation mechanism. Every time the value of the class node data changes the Groovy class will be recompiled.

Generated at Mon Feb 12 05:56:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.