Page History
...
In no particular order, here's a quick breakdown of independent features:
...
...
...
...
...
...
Magnolia.home
The Magnolia webapp should be markable as read-only; module jars should be loadable from outside the webapp folder (we don't want to(can not) write inside /WEB-INF/). Other files (repository, indexes, cache, ...) should also be written outside the webapp. See MAGNOLIA-2170@jira and the linked user-list thread for some background discussion.
...
...
...
...
| | | | |
Split core
Magnolia-core will probably have to remain in the webapp folder: extract more out of core, so that it can also benefit from easy updates.
...
...
...
...
...
| | | | |
Hot (re)deploy
| Wiki Markup |
|---|
...
No need to restart the app/appserver to deploy a module update. ("updates are ready: \[apply now, silently\] or \[click here for switching to the update UI when ready\]"; alternatively, we could maybe make it so that the system still works while updates are being applied, and switches "atomically" at the end? - or at least provide a configurable temp page for public instances)
We can already restart a module. Missing points: * restart this module's dependencies in the appropriate order. (restarting all is probably good enough) |
- load modules in an isolated classloader, so hopefully, we can swap to the new jars once they're downloaded. We have some experience w/ classloaders, see magnolia-tools ! (+include classloader debug info in the diagnostics module !)
- what happens to the public site while updating (is Magnolia accessible, do we have a temp page) | out of scope | | | |
...
Hot (re)deploy
...
No need to restart the app/appserver to deploy a module update. ("updates are ready: [apply now, silently] or [click here for switching to the update UI when ready]"; alternatively, we could maybe make it so that the system still works while updates are being applied, and switches "atomically" at the end? - or at least provide a configurable temp page for public instances)
...
...
...
...
...
Uninstall modules
Most of our modules are actually fairly easily uninstallable (see docu, it's mostly removing the jar and removing a few specific nodes), so this should be feasible. Provide backup of removed nodes for safety. Uninstalls could be "automatic" when a jar removal is detected (i.e when restarting the server) or done through some form of gui. Potential implementation would imply serializing the tasks-for-uninstalling at install time. (store result of ModuleVersionHandler.getUninstallTasks())
...
...
...
...
| | | | |
Security
The current update UI is totally open: provide a better/configurable page for public instances while updates are being performed.
...
...
...
| | | | MAGNOLIA-1629@jira |
System workspace
We're currently store the module related information in the configuration workspaces, in various places: current module version under /module/xyz/version, backup of some config nodes under /server/install/backup, information about extracted files under /server/install/mgnl-files. We could instead use a specific workspace.
...
| | | | |
...
...
...
...
External libraries
Modules need to be bundled with 3rd party libs (e.g Quartz with the Scheduler module). Current limitation of our module system is that we don't provide any "check" - e.g Scheduler module bluntly fails to start after installation; thus blocking the complete system.
...
...
...
...
| | | | |
UI
Missing dependencies should be reported in the ui.
...
...
...
...
| | | | |
Server side
Where and how do we deploy and publish modules.
...
...
...
...
| | | | |
Versions, dependencies
Our current dependency system can state a minimal required version (i.e module X depends on Y 1.3 and up and on core 4.1 and up. Somehow, we'll have to be able to also say that module X 1.2 will not work anymore with Y 1.5, which is not something that we can determine when X is released. So this is probably something that needs to happen on the server-side of things.
...
...
...
...
| | | | |
Detecting inter-module dependencies
...
...
...
...
| | | | |
Handling of module's own dependencies (i.e non-Magnolia)
We can't detect them, but since our current build generates bundles including them, we could possibly do something about that.
...
| Additionally, if the Maven team do the same work for other Maven components than what they've done for Mercury, there might be a simple and small API to read a module's pom, and thus derive the external dependencies from.
...
...
...
...
| | | | |
Downloading artifacts
...
Downloading artifacts
...
...
...
...
...
Updating a module without restarting the app container
...
We can already restart a module. Missing points: * restart this module's dependencies in the appropriate order. (restarting all is probably good enough)
- load modules in an isolated classloader, so hopefully, we can swap to the new jars once they're downloaded. We have some experience w/ classloaders, see magnolia-tools ! (+include classloader debug info in the diagnostics module !)
- what happens to the public site while updating (is Magnolia accessible, do we have a temp page)
...
out of scope
...
...
...
...
Uninstalling a module
...
not implemented. Implementable. (would need some form of gui, or serializing the tasks-for-uninstalling at install time)
...
...
...
...
Existing implementations, libraries, ...
...
Overview
Content Tools