org.glassfish.api.admin
Annotation Type Supplemental


@Retention(value=RUNTIME)
@Contract
@InhabitantAnnotation(value="default")
public @interface Supplemental

Annotation to define a supplemental command A supplemental command runs when a main command implementation is ran, it can be used to attach behaviours to existing commands without modifying the original implementation.

A supplemental command can be very useful to configure extra or external components of an installation. For instance, a load-balancer module can be installed when a load-balancer is added to a glassfish installation. Such module can contain supplemental commands to supplement commands like "create-instance" in order to update the load-balancer specific information.

An implementation must use the value() attribute of the @Supplemental annotation to express the supplemented command. Its value is the name of the command as defined by the supplemented command @Service annotation.

Example : take a command implementation

 
 @Service(name="randomCommand")
 public MyRandomCommand implements AdminCommand {
 ...
 }
 
 

a supplemental command may be defined as follows :

 
 @Service(name="mySupCommand")
 @Supplemental("randomCommand")
 public MySupplementalCommand implements AdminCommand {
 ...
 }
 
 

Another implementation that does not use the same parameter names as the supplemented command will need to use a @Bridge annotation

 
 @Service(name="otherSupCommand")
 @Supplemental(value="randomCommand" bridge=MyParameterMapper.class)
 public OtherSupplementedCommand implements AdminCommand {
 ...
 }
 
 

There can be several supplemental commands for a command implementation.

A supplemental command can be executed in "isolation" (not part of the supplemented command execution) and should not make any assumption that it is called as part of its supplemented command execution. If a command should not be invokable in isolation, it must not define a name() attribute on the @Service annotation :

 
 @Service
 @Supplemental("randomCommand")
 public MySupplementalCommand implements AdminCommand {
  // can only be invoked as a supplemental command
 }
 
 

If a supplemental command is annotated with @Rollback, the annotation will be ignored when the supplemental command is executed in isolation.

If a supplemental command is annotated with @Rollback, it is still subject to the supplemented command ExecuteOn.ifFailure() value to decide whether or not roll-backing should happen in case of failure.

When associating a supplemental command to a command X, it's always a good idea to associate a roll-backing supplemental command to the rollbacking command of X. For instance, if an "add-lb-config" supplemental command is attached to the "create-instance" command, a "delete-lb-config" supplemental command should be attached to the "delete-instance" command.

Author:
Jerome Dochez

Required Element Summary
 java.lang.String value
          Name of the supplemented command as it can be looked up in the habitat.
 
Optional Element Summary
 java.lang.Class<? extends ParameterBridge> bridge
           
 FailurePolicy ifFailure
          Indicates to the framework what type of action should be taken if the execution of this command was to return a failure exit code.
 Supplemental.Timing on
          Supplemental commands can be run before or after the supplemented command.
 

Element Detail

value

@InhabitantMetadata(value="target")
public abstract java.lang.String value
Name of the supplemented command as it can be looked up in the habitat. * Therefore the supplemented command must have the AdminCommand type and the provided registration name.

Returns:
habitat registration name for the command

bridge

public abstract java.lang.Class<? extends ParameterBridge> bridge
Default:
org.glassfish.api.admin.ParameterBridge.NoMapper.class

on

public abstract Supplemental.Timing on
Supplemental commands can be run before or after the supplemented command. Returns when this supplemental command is expecting its execution.

Returns:
Before if it should be run before the supplemented method or After if it should run after the supplemented method.
Default:
org.glassfish.api.admin.Supplemental.Timing.After

ifFailure

public abstract FailurePolicy ifFailure
Indicates to the framework what type of action should be taken if the execution of this command was to return a failure exit code. The action will apply on the supplemented command as well as all supplemental commands.

If rollback is expected, the failure of this supplemental command will cause the rollbacking of all the already executed supplemented commands as well as the main supplemented command.

Returns:
the action the framework is expected to invoke when this supplemental command execution failed.
Default:
org.glassfish.api.admin.FailurePolicy.Error


Copyright © 2012 GlassFish Community. All Rights Reserved.