[MAGNOLIA-6846] Resource directories registered via symbolic links are skipped by the directory watcher Created: 26/Oct/16 Updated: 27/Feb/18 Resolved: 18/Nov/16 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 5.4.9, 5.5 |
| Fix Version/s: | 5.4.10, 5.5.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Tomáš Gregovský | Assignee: | Aleksandr Pchelintcev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| 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)
|
||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Sprint: | Basel 71 | ||||||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||||||
| Description |
|
Corporate website is running on 5.4.9 and we using light modules there (on file system). Everytime when new decoration file is added, and 'git-pulled' from git repo to light modules folder on instance they doesn't apply immediately. Log doesn't say anything about detecting new decoration either. Checking resource files app shows that decoration file exists. One instance is restarted, message about this decoration file is printed in log and after restart decoration is applied. It happends in all instances (author/public1/public2). We using symbolic link for 'light-modules'. Info about server: |
| Comments |
| Comment by Aleksandr Pchelintcev [ 03/Nov/16 ] |
|
tgregovsky You're saying here that it happens every time on any instance, but when we've been discussing this previously - I thought you told that for some instance it might work for some other - it might not (e.g. decoration would be applied on one public instance, but not on the other). I just want to make sure - so the file creation event is never ever fired on public instances, right? |
| Comment by Tomáš Gregovský [ 03/Nov/16 ] |
|
apchelintcev hi, first time when I called you I was thinking it happens only on public, but later during testing I found it on all instances, including author.... |
| Comment by Tomáš Gregovský [ 09/Nov/16 ] |
|
BTW issue with symbolic links seems bigger... just discovered that every file which is new file (with definition) is not observed, only files which are modified are ok. Just created few new component definitions for corporate website and none of them is in registry. But all of them I can see in Resource Files app, same as update component with added availability is updated in registry, but referencing definitions which are not As a workaround I have to restart author and all publics after each new definition or decoration... |
| Comment by Tomáš Gregovský [ 14/Dec/16 ] |
|
cmeier Yes you can create a symbolic link in location of 'magnolia.resources.dir' which is pointing to light module somewhere else in file system. I am using it heavily, because LMs are usually single projects with its own git while webapp or parent is another git project (and is not easy to have one or more git projects inside another). But this works many Magnolia versions already, except situation when you change something (in that symbolic link location), and running Magnolia doesn't pick up that change - doesn't see that it was changed, so it doesn't update it in registry. (that was a reason of this ticket). Not sure about final fix, but at some point Sasa gives me snapshot version of fix which we applied and after it it works nicely. |
| Comment by Christopher Zimmermann [ 16/Jan/17 ] |
|
For the testers - was this tested on Windows? |
| Comment by Christopher Zimmermann [ 31/Jan/17 ] |
|
I have confirmed that symbolic links work on Windows. |