-
Notifications
You must be signed in to change notification settings - Fork 55
Openshift server adapter profile and its subsystems
Some time ago @robstryker created API for handling server types that need to delegate their behavior based on settings on a server. He described the idea in a blog post here: https://developer.jboss.org/wiki/JBossTools-DelegatingServersViaSubsystems.
Shortly, two extension point were created: org.jboss.ide.eclipse.as.wtp.core.serverSubsystem and org.jboss.ide.eclipse.as.wtp.core.serverProfile. The first one has 2 main elements: subsystem and subsystemMapping. subsystem has fields:
-
systemwhich represents the operations that can be done to the server, for example launch, publish, shutdown -
class- the class which represents some implementation of thesystem
Every subsystem needs to be assigned to the server type. subsystemMapping is used for this and has
-
mappedId- the id of the subsystem -
serverTypes- comma-separated list of server types the subsystem will be applied to
The next question is what susbsystem is used when multiple of them are declared for one server type. For that purpose we should use the second extension point mentioned above: org.jboss.ide.eclipse.as.wtp.core.serverProfile. You can think of a profile as a set of subsystems for a server type. Server profile must include only one subsystem per system, otherwise an exception is raised, because it's not clear what subsystem to use. The profile is set into the "org.jboss.ide.eclipse.as.core.server.serverMode" property of the server adapter.
The default profile for the Openshift server adapter is "openshift3". If you want to assign a different profile for your openshift server adapter, you need to extend the org.jboss.tools.openshift.core.serverAdapterProfileDetector extension point. All extensions are run through during the creation of the openshift server adapter. The classes of these extensions are called, that must detect if an eclipse project and an openshift resource, which the server adapter is being created for, are suitable for your new profile. If none of the detectors is satisfied then the default "openshift3" profile is assigned.
Some of the subsystems for "org.jboss.tools.openshift.server.type" are not included into any of the profiles. That's why now they have a property "default" set to "true". This is done because otherwise these subsystems will be automatically applied to its systems of all profiles, even if they define their own subsystem for some system. This situation causes 2 subsystems suitable for 1 system and raises exception. "default=true" helps resolve it and exclude default subsystem if another one found in a profile
Q: Profile defines mapping between server type and subsystem itself. Do i need to create subsystemMapping anyway?
A: Yes. The profiles was a better solution all-around, however subsystemMappings were implemented first and extended by lots of extensions by the time profiles were created. By now we need to create subsystemMapping for every subsystem and then also add them to profile.
Q: What is the behavior(for example, OpenShiftServerBehaviour; extensions of org.eclipse.wst.server.core.model.ServerBehaviourDelegate)?
A: The server behavior is used to have all of the systems (start / stop / publish / module state) all in 1 place