[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: |
| Description |
| 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.
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.
|