4

Is there a way to force the load/evaluation order of alfresco share extension modules?

We currently have two extension modules defined in module-general.jar and another module defined in project-specific.jar The modules in module-general.jar customize functionality applied to all sites like allowing only creation of private sites and the like.

The module in project-specific.jar depends on being loaded/evaluated after the other general modules to work correctly.

When the modules are added to the set of "Deployed Modules" and the "Apply Changes" button is pressed, then everything works as expected.

The module order is as follows:

GEN (00) Hide Create Site
GEN (01) Manage Permissions
PRO_ID Manage Permissions

After restart of Alfresco/tomcat and a http GET on http://localhost:8080/share/page/modules/deploy the order of the active modules is different and the "Manage Pemissions" functionality is no longer working as expected for the project requesting it.

The module order after server restart is as follows:

PRO_ID Manage Permissions
GEN (00) Hide Create Site
GEN (01) Manage Permissions

How can we make sure that the "general" customization modules are loaded/evaluated before the project specific ones as they were activated before server restart?

Regards

Andreas

Alfresco 4.0.2.9/Tomcat/Win7

tullo
  • 43
  • 2

3 Answers3

2

use tag auto-deploy-index in share module xml file lower the number higher the priority

k10ml
  • 116
  • 9
1

You should specify the dependencies in your module.properties files, as described in the wiki. For GEN (00) Hide Create Site you don't have to do anything. For GEN (01) Manage Permissions you need something like:

module.depends.com.tullo.alfresco.module.gen00=1.0-*

and for PRO_ID Manage Permissions:

module.depends.com.tullo.alfresco.cmodule.gen01=1.0-*

Adapt the above to the real ids and versions of the modules you developed.

skuro
  • 13,414
  • 1
  • 48
  • 67
  • The modules are developed as Share extension modules contained in two jar-files that just can be copied to tomcat/shared/lib. The referenced wiki entry is focused on AMP based modules, which I believe is not applicable in this case, I guess. – tullo Feb 18 '13 at 22:28
  • The solution could then be to package the extensions as Share AMP:s instead? – billerby Feb 19 '13 at 07:10
  • Unfortunately I don't think this will help here. Whilst one can supply a Share Extensibility module inside an AMP rather than a JAR, once installed the loading order of those modules is independent of any dependencies specified by the AMP. – Will Abson Feb 19 '13 at 10:11
  • AFAIK you can use AMP files in Share as well, even if JAR extensions are easier to handle you would get more control over them, e.g. ordering their boot sequence – skuro Feb 19 '13 at 21:06
1

It is not currently possible to declare dependencies in Share Extensibility modules, like one can with AMPs.

The order in which modules are loaded when they are first added to Share is therefore not guaranteed.

Modules can be re-ordered by an administrator in the Module Deployment console, and this is the method I have used to ensure that dependent modules are loaded after modules on which they depend (see my Tech Talk Live from last week for examples of this).

Unfortunately, this ordering is not persisted for modules with the auto-deploy flag set to true. This is because auto-deployment is not able to persist state to the repository (since there is no active user session). Auto-deployed modules are re-deployed each time the server is restarted, and this is why they end up re-appearing at the end of the list.

The solution is to avoid using auto-deployment for any modules where the loading order matters. I found that after making the necessary code change in my module descriptors I had to remove all my modules and apply changes, before re-adding them in the correct order and clicking apply changes again.

Will Abson
  • 1,562
  • 7
  • 13
  • After having disabled auto-deployment for all modules I have moved them all over to "Available Modules" and applied changes. Re-added the modules in correct order and applied changes. Unfortunately the module ordering is wrong again after server restart. Should that work on Alfresco 4.0.2.9 also? – tullo Feb 19 '13 at 12:12
  • It took me a couple of tries and possibly a few restarts before the ordering started working reliably for me again. Did you disable auto-deployment in the modules themselves? – Will Abson Feb 19 '13 at 12:22
  • Yes, all module discritpors disable auto-deployment. Also set enable-auto-deploy-modules to false in share-config.xml. So I no longer see "alfresco could not save module deployment for yyy" at Share startup. But that did not cure it. Going to wipe the database and contentstore now for a fresh start. – tullo Feb 19 '13 at 13:27