[MAGNOLIA-2170] Webapp should be markable as read-only Created: 05/Jun/08 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | build, core |
| Affects Version/s: | 3.5.8 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Dan Greening | Assignee: | Magnolia International |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | freemarker | ||
| 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)
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Description |
|
Ideally, it would be possible to make the servlet container read-only, storing the repository and template files (and any other writable files) outside the app directory. This would allow for "instant upgrades" by just dropping in a new WAR file. Today, I think, Magnolia really violates the principles of a WAR file, which is that it should be self-contained and not writable. I attempted to remove all writable/changable files and directories to outside the directory, and then marked the app directory read-only to diagnose problem areas. In Tomcat, it is possible to configure the magnolia.properties file location outside the app directory (and by changing that version of magnolia.properties, you can move the repository directory) out of the servlet container. However, you cannot relocate template files outside the app. In addition, the installation process makes changes to the contents of the app directory; kind of annoying. Would be used by many, I suspect. |
| Comments |
| Comment by Philipp Bracher [ 05/Jun/08 ] |
|
I agree. But the main obstacle is that the jsps have to reside in the webapp itself (or am I wrong here?). As soon as we use an other template mechanism (like freemarker) we would even be able to store the templates in the repository. |
| Comment by Magnolia International [ 05/Jun/08 ] |
|
Dan - as Philipp said, you can't have JSPs outside the webapp. We extract them out of the module's jars because they also have to be on the filesystem, not just the classpath. I'm pretty sure some containers would allow having the JSPs outside the webapp, but I'm also pretty sure it would bring more problems that it'd solve (configuration of the container, includes, forwards, blah). Currently, you can already have freemarker-based paragraph templates. Once we have freemarker support for page template, your dream will come true :-D (or did you notice any other files being written to the fs in the webapp, which were not relocalizable ?) |
| Comment by Magnolia International [ 08/Oct/08 ] |
|
Just committed a FileTemplateLoader which can be configured with content2bean - info.magnolia.module.templating.LazyFileTemplateLoader - package and class name subject to change |
| Comment by Dan Greening [ 08/Oct/08 ] |
|
Would really appreciate if you would test this by configuring template and configuration outside the exploded WAR area, then mark the WAR area read-only. Can you then drop-in a new WAR and it continues to work as before? (I say this because I'm not entirely sure that Templates are the ONLY issue.) |
| Comment by Magnolia International [ 09/Oct/08 ] |
|
Having the repository outside has been possible for as far as I've been using and working with Magnolia, by setting the magnolia.repositories.home in magnolia.properties Indexes are in there too. Cache and tmp directories are also configurable through magnolia.properties. With 3.7 you'll have the possibility to have your (freemarker) templates either (or both) outside the webapp, (anywhere on the filesystem) or in the repository. I've been working for a little while with a non-exploded war in jetty and haven't noticed anything else that needed to write to the filesystem, but if you have a specific setup in mind and some time on your hands, by all means, please try a 3.7 snapshot (we can upload some for you, but you'll want to build your own war anyway) One extra option would be (and it might already be feasible, would have to check) to be able to specify the location of the magnolia.properties file through a jvm/system property. At the moment, the locations where its looked for are specified in the web.xml and this mechanism is explained here: http://documentation.magnolia.info/cookbook/using-a-single-war-file-with-multiple-configurations.html |
| Comment by Magnolia International [ 09/Oct/08 ] |
|
Re-read your initial comment; could you elaborate on "in addition, the installation process makes changes to the contents of the app directory". I'm not sure what this is about. Thanks. |
| Comment by Magnolia International [ 26/Jan/09 ] |
|
Generalizing the issue - we should be able to completely mark a Magnolia war as read-only.
Todo : validate all other options, possibly improve - for instance we could introduce a magnolia.home property. It should be configurable outside the webapp (i.e as a context parameter or system property), to further improve on the "single war, multiple configurations" feature. |
| Comment by joshua portway [ 18/Mar/09 ] |
|
I'm not sure it's necessary to make the app directory completely read-only. I think it's legitimate that some modules might want to write data to the app directory on install (eg templates etc.). I also think it's reasonably to use the app directory for caches etc (my image server module creates a cache directory inside the app, for instance). I think the problem comes when the app directory is treated as a persistent data store. Because (as has been mentioned) the app directory usually gets completely overwritten when an app is deployed, any files written to the application directory should either be temporary files or be capable of being re-created on demand. The only real symptom I see of this problem is that currently the mgnl-files mechanism does not replace missing files on application startup (I assume that a missing file is treated as a customisation). So any module that installs files using the mgnl-files mechanism will break as soon as the application is redeployed - since the files it expects to be available aren't there any more. It seems to me that the answer would be for the mgnl-files mechanism to simply replace any missing files on startup rather than treat them as customisations. If a developer really wanted to customise an installation by removing a file then they could set a flag in the config/server/install/mgnl-files nodes to block the re-installation. That's a bit more hassle than simply deleting a file, but it does have advantages - it makes the developer's intent explicit and it also allows them to undo the decision if it was a bad idea. |
| Comment by Magnolia International [ 20/Mar/09 ] |
|
See http://www.nabble.com/problems-with-mgnl-files-td22577725.html for reference. One issue is that we need a mechanism to re-extract files when a war file was updated. In Joshua's scenario for instance, Magnolia itself isn't updated, so, for instance, the dms jsp template isn't re-extracted; however, since he's deploying a new war file, the files need to be re-extracted. Note that it seems to me that the only case where this is really an issue is with JSPs, as they can't be outside the webapp folder (although maybe future versions of the spec will address this issue?) – any other file can probably be outside; as such, maybe we should introduce a different mechanism and really treat JSPs specifically ? |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |