Page History

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.

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c9927e38-5efc-4139-a931-1ff7f3757bbc"><ac:plain-text-body><![CDATA[

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)

]]></ac:plain-text-body></ac:structured-macro>

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.