This extension point allows tool-writers to extend the capability of the Remote System Explorer, by identifying a subsystem configuration that produces a subsystem whenever a new connection is created. This subsystem appears under the connection when it is expanded in the Remote Systems view of the Remote System Explorer perspective. The subsystem configuration is called by the Remote System framework when the user creates a new connection, when the connection's system type is one of the types identified as supported by this subsystem configuration extension.
There is one subsystem object per connection, and the role of a subsystem is to allow
users to work with remote resourcesfor the remote system identified by the containing connection. Defining a subsystem configuration involves more than the single subsystem
configuration class. There must also be a subsystem class defined, and a system class defined. There may also be other classes defined, such as classes for the content area of wizards for defining filters, user actions and compile commands, if the subsystem configuration wishes to support these. See the developer documentation for the Remote System Explorer for documentation details on defining subsystems.
A class that implements <samp>org.eclipse.rse.core.subsystems.ISubSystemConfiguration</samp>.
It is recommended to extend <samp>org.eclipse.rse.core.subsystems.SubSystemConfiguration</samp> or <samp>org.eclipse.rse.core.servicesubsystem.ServiceSubSystemConfiguration</samp>.
A semicolon separated list of system type ids that subsystems from this configuration support. For example, <code>"org.eclipse.rse.systemtype.unix;org.eclipse.rse.systemtype.linux"
</code>.
<p/>
The wildcards '*' and '?' are accepted. Therefore, if a subsystem configuration should be registered against all existing system types, this slot should be set to <code>"*"</code>.
This optional attribute allows subsystem providers to classify the type of remote resources that are listed by this subsystem configuration. It is possible for
multiple subsystem factories to support the same remote resource category. This category is used in the popupMenus and propertyPages extension points, to scope actions and property pages to only remote resources of a particular category, via their <samp>subsystemconfigurationCategory</samp> attribute.
For example, if listing database resources you might specify a category of "database".
This optional attribute determines the order in which subsystems appear in the New Connection wizard and RSE views. Integer values are allowed. Subsystems with lower number will appear first in the RSE tree. Subsystems that do not define the priority attribute will be appended last to the list of subsystems.
Note that ServiceSubSystems that share the same service should always use the same priority, since their service implementation can change at runtime. The following priorities are used by the predefined subsystems: files=100, processes=200, shells=300.
Defining the xml for the extension point is easy. There is a fair amount to know about
creating the classes needed for a subsystem configuration, however. For this information, consult the Remote System Explorer developer documention, including the JavaDoc for the supplied classes and interfaces for this task.
