Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Openshift server adapter profile and its subsystems
serverSubsystem and serverProfile idea shortly
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.serverProfile. The first one has 2 main elements:
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 the
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
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
A: The server behavior is used to have all of the systems (start / stop / publish / module state) all in 1 place