Interface IApplicationBehaviourDelegate

All Known Implementing Classes:
InfobaseApplicationBehaviourDelegate, ServerApplicationBehaviourDelegate

public interface IApplicationBehaviourDelegate
Application type specific implementation of application operations.

Usually, application code should use IApplicationManager which could then delegate to instances of IApplicationBehaviourDelegate for application type specific behavior.

  • Method Details

    • initialize

      void initialize(IApplicationProvisionNotifier notifier, IApplicationType type) throws ApplicationException
      Initializes the application behavior delegate with the registered application type and provision notifier.
      Parameters:
      notifier - the application provision notifier, cannot be null
      type - the application type, cannot be null
      Throws:
      ApplicationException - if method call failed with some reason
    • update

      ApplicationUpdateState update(IApplication application, ApplicationUpdateType updateType, ExecutionContext context, org.eclipse.core.runtime.SubMonitor monitor) throws ApplicationException
      Updates infobase configuration as per project state.

      Project and infobase are determined by the application.

      Parameters:
      application - Application determining project and infobase to update. Must not be null.
      updateType - Determines if just changes in the project should be loaded into the infobase or infobase configuration should be reloaded fully. Must not be null.
      context - the execution context, cannot be null
      monitor - the progress monitor to report progress to, cannot be null
      Returns:
      New state of the application. Never null.
      Throws:
      ApplicationException - if method call failed with some reason
    • check

      org.eclipse.core.runtime.IStatus check(IApplication application, ApplicationCheckUnknownStateTreatment whenUnknown, ExecutionContext context, org.eclipse.core.runtime.IProgressMonitor monitor) throws ApplicationException
      Checks whether the application is ready to start.

      Such readiness check might include checking that related infobase configuration has not been changed outside of EDT. If application's project has extensions then those extensions are checked as well.

      Parameters:
      application - the application to check, cannot be null
      whenUnknown - Indicates how to treat situation when previous infobase state is not known and so cannot determine if there are changes in infobase. Must not be null.
      context - Context with start parameters. It must contain ExecutionContext.ACTIVE_SHELL_NAME with the shell to be used for interaction with a user. Must not be null.
      monitor - the progress monitor to report progress to, cannot be null
      Returns:
      IStatus.OK if application is ready to be started, IStatus.CANCEL if user cancels operation, IStatus.ERROR if application is not ready to be started.
      Throws:
      ApplicationException - if the context does not specify ExecutionContext.ACTIVE_SHELL_NAME or pulling changes from the associated infobase fails.
    • prepare

      void prepare(IApplication application, String launchMode, ExecutionContext context, org.eclipse.core.runtime.SubMonitor monitor) throws ApplicationException
      Prepares underlying infrastructure to be ready for interaction.

      Some applications might consist in more than just a client. Those type of applications might require additional set up for the interaction with them to function properly. For example, a server application might require a server to be started before a client application can be #publish-ed or client started. Such preparation work is performed by the method. The opposite work of undoing such preparation should be done with cleanup(com.e1c.g5.dt.applications.IApplication, com.e1c.g5.dt.applications.ExecutionContext, org.eclipse.core.runtime.SubMonitor).

      The application preparation for regular run and for debug run might be significantly different. The caller must specify launch mode to be the same as it will specify when actually starting application in the future. However, it is up to the application if it will honor or ignore the mode and if it will re-prepare if it is already prepared for another mode or the current application state is good enough for the desired launch mode.

      The current thread is blocked until preparation is complete (for example, server start finishes). Since this is a long running operation, it might be inappropriate to run it from UI thread. Consider using org.eclipse.jface.dialogs.ProgressMonitorDialog with fork mode enabled.

      Parameters:
      application - the application to prepare, cannot be null
      launchMode - Desired future application start mode. See org.eclipse.debug.core.ILaunchManager.RUN_MODE and org.eclipse.debug.core.ILaunchManager.DEBUG_MODE. Must not be null.
      context - Context containing parameters affecting application preparation. The context could be modified as a result of the call and should be used when starting clients. For example, ExecutionContext.DEBUG_TARGET and ExecutionContext.DEBUG_URL might be added/updated to reflect application settings when preparing for debug mode. Must not be null.
      monitor - the progress monitor to report progress to or null if report is not desired
      Throws:
      ApplicationException - if method call failed with some reason
    • cleanup

      void cleanup(IApplication application, ExecutionContext context, org.eclipse.core.runtime.SubMonitor monitor) throws ApplicationException
      Cleans up resources associated with the application.

      The method does not stop client application being developed. Instead, it undoes preparation work that has been previously done by prepare(com.e1c.g5.dt.applications.IApplication, java.lang.String, com.e1c.g5.dt.applications.ExecutionContext, org.eclipse.core.runtime.SubMonitor). For example, if for a server application a server itself has been started by prepare(com.e1c.g5.dt.applications.IApplication, java.lang.String, com.e1c.g5.dt.applications.ExecutionContext, org.eclipse.core.runtime.SubMonitor) and then a client application has been started then the method might stop that previously started server once it is not needed anymore.

      This can change life-cycle state of the application but should have no effect on application synchronization/equality/publish state. Cleanup is a temporary action and should not be as destructive as delete(com.e1c.g5.dt.applications.IApplication, boolean).

      The current thread is blocked until operation is finished. Since this is a long running operation, it might be inappropriate to run it from UI thread. Consider using org.eclipse.jface.dialogs.ProgressMonitorDialog with fork mode enabled.

      Parameters:
      application - the application to stop, cannot be null
      context - the execution context, cannot be null
      monitor - the progress monitor to report progress to, cannot be null
      Throws:
      ApplicationException - if method call failed with some reason
    • delete

      void delete(IApplication application, boolean unsynchronize) throws ApplicationException
      Deletes the specified application.
      Parameters:
      application - Application to be deleted. Must not be null.
      unsynchronize - true if synchronization state is to be deleted or false is to keep synchronization state.
      Throws:
      ApplicationException - If the specified application could not be deleted for whatever reason.
    • onStateChanged

      void onStateChanged(IApplication application, LifecycleState state)
      Called when application state has been changed.
      Parameters:
      application - Application whose state has changed. Never null.
      state - State in which application has been transitioned. Never null.