Ticket #324 (closed Enhancement: fixed)

Opened 8 years ago

Last modified 5 years ago

The plugin services should be available in migrations

Reported by: jri Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.0.12
Keywords: Cc: dgf, Malte
Complexity: 5 Area: Application Framework / API
Module: deepamehta-core

Description

This easifies writing migrations and is less error prone.

Change History

comment:1 Changed 8 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by jri

  • Milestone changed from Release 4.1 to Release 4.2

comment:3 Changed 6 years ago by jri

  • Milestone Release 4.2 deleted

comment:4 Changed 5 years ago by Jörg Richter <jri@…>

In b7572f5cd8fd873a89d91de3ff8bfae7213c2888/deepamehta:

Core: inject services into migrations (#324).

Plugin services can be injected into (imperative) migrations by using the @Inject annotation.

Example (an Access Control migration consumes the Workspaces service):

package de.deepamehta.plugins.accesscontrol.migrations;

import de.deepamehta.plugins.workspaces.service.WorkspacesService;
import de.deepamehta.core.service.Inject;
import de.deepamehta.core.service.Migration;

public class Migration5 extends Migration {

    @Inject
    private WorkspacesService wsService;

    @Override
    public void run() {
        // wsService is available here
    }
}

IMPORTANT: the services a plugin's migrations can consume are limited to those services the plugin consumes anyways. If you need other services in a migration inject them to the plugin as well.

See #324

comment:5 Changed 5 years ago by Jörg Richter <jri@…>

In 5ed342855656646f686908456aab04f81d334712/deepamehta:

Core: inject own service into migration (#324).

Also the plugin's provided service can be injected into the plugin's *own* migrations.

Example (here an Access Control migration consumes the Workspaces service AND the Access Control service itself):

package de.deepamehta.plugins.accesscontrol.migrations;

import de.deepamehta.plugins.accesscontrol.service.AccessControlService;
import de.deepamehta.plugins.workspaces.service.WorkspacesService;
import de.deepamehta.core.service.Inject;
import de.deepamehta.core.service.Migration;

public class Migration5 extends Migration {

    @Inject
    private AccessControlService acService;

    @Inject
    private WorkspacesService wsService;

    @Override
    public void run() {
        // acService and wsService are available here
    }
}

IMPORTANT: at the time the plugin's service is injected into the plugin's *own* migrations, the plugin is not yet fully activated. In particular (besides others):

  • the plugin's init() hook is not yet invoked.
  • the plugin's listeners are not yet registered.

Keep this in mind when using a plugin service from within this plugin's own migration.

This particularity only applies to the plugin whose service is consumed by its *own* migrations. It does *not* apply to the *other* plugins whose services are injected into this plugin's migrations. These plugins *are* fully activated.

Note: this particularity is not resolvable as circularity is involved here.

See #324

comment:6 Changed 5 years ago by jri

Since we have access to plugin services within a migration there is no need for the postInstall hook anymore. The post-install action can be seen just as another migration. In favor of reduced complexity the postInstall hook should be dropped.

comment:7 Changed 5 years ago by Jörg Richter <jri@…>

In 3b4497838ca82b75c6131c14a023b634158e19b3/deepamehta:

Access Control: refactor migrations (#592, #324).

In case of updating an existing installation to DM 4.5: this migration reconstructs the user's memberships by the means of 4.5's Membership associations. This works in particular when several workspaces and user accounts have been created in the pre-4.5 installation.

The Access Control migrations are refactored: the plugin makes no use anymore of both, the postInstall() hook, and the allPluginsActive() listener. These actions performs as migrations now, which makes the control flow and code more clear.

See #592
See #324

comment:8 Changed 5 years ago by Jörg Richter <jri@…>

In 237eb289bf4dbd53ba6619fa4f27e44f70f80e2c/deepamehta:

Worspaces plugin: refactor migrations (#324).

The Workspaces plugin makes no use of the postInstall() hook anymore. This action performs as a migration now, which makes the control flow and code more clear.

See #324

comment:9 Changed 5 years ago by Jörg Richter <jri@…>

In 5f0521ae9b6c7c65833babb2fd61eb0febe6934f/deepamehta:

Plugin framework: drop postInstall() hook (#324).

You can do the same with a migration.

See #324

comment:10 Changed 5 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.