[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:
dependency
depends upon MAGNOLIA-2582 Make Freemarker template loaders conf... Closed
relation
is related to MGNLDATA-95 Make location of the backup folder fo... Closed
is related to MAGNOLIA-1482 Templates stored in repository Closed
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.

  • JSPs are not useable outside the webapp - so this won't work for JSPs in modules.
  • Our Freemarker support now provides configurable template loaders, and we provide a configurable LazyFileTemplateLoader, so Freemarker templates can reside outside the webapp.

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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:34:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.