Currently the server tools framework has a separate notion
of runtime and a server. Typically, the runtime is supposed to represent the server
install location, while server instance supposed to represent an actual
runnable server configuration. The runtime then functions almost like a factory
for server instances. You can have any number (including zero) of server
instances associated with a runtime. While that separation can be a good thing
in some situations, it’s has turned out to be in a problem in others. In
particular:
- The runtime is supposed to be a
full description of the server, including its capabilities (which facets
are supported). While that is true in some cases, often the actual server
configuration is necessary in order to get the complete understanding of
what’s supported. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=111545
for one example of this.
- Having to create and maintain
separate lists of runtimes and servers has shown to be confusing for
users. Extra steps are necessary. The user has to know about the
preferences page for managing runtimes and the servers view for managing
servers. Often there is confusion as to which one you are talking about. People
use terms server and runtime interchangeably, etc.
- Some runtimes (such as Tomcat) do
not have additional server configuration, in which case the extra step of
creating a server from a runtime is very unnecessary.
I’d like to propose that the server runtime and server
instance be merged into one. I believe we can do that without detriment to the
use cases that gave rise to the separation. We can do that by allowing a
runtime to also (optionally) be a server. That is, all servers would be
runtimes, but not all runtimes would be servers. When creating a runtime via
the new runtime wizard, the runtime provider will have full flexibility in
determining whether the runtime that’s created is a server or not. Some
runtime providers (such as Tomcat) may always create servers. Others, such
WebLogic, may do that optionally based on user’s input. For instance, if
the user specifies just the WebLogic install location, then the created runtime
would not be a server, but if the user also provides the domain configuration directory,
then the runtime becomes a startable server. A project can be targeted to
either one for development, but only the latter one can be used to run/debug
the app. This approach places a lot of flexibility in the hands of the runtime
providers. It’s conceivable that some may even allow a runtime that’s
not a server to be “converted” into a server by specifying
additional information.
The users would manage the list of runtimes via a new
Runtimes workbench view. The view would be extensible, allowing the server
tools framework to plug in and mark those runtimes that are servers with decorations
and additional actions, such as start, stop, and status monitoring. This would
replace the dedicated Servers view.
At the api level, IRuntime would be adaptable to IServer (as
applicable) and IServer would be adaptable to IRuntime (always). The server
tools would maintain the markers that indicate which runtimes are servers and
surface this via api for use by the runtime providers. This would not be
surfaced to the end user via UI.
So how would we handle use cases that drove to the
separation of the runtime and the server?
- I want to just write code. I haven’t
created a server and I don’t want to create one. I will worry about
running/debugging later. The above proposal leaves this in the hands of
runtime providers. If creating a server instance configuration is not
trivial, the new runtime wizard should let the user opt out of that. The
end result would be an un-runnable runtime that the user can still develop
against.
- I don’t want to have to
specify the location of my server install every time I create a new server
instance. This can easily be handled in the runtime creation wizards by
remembering the prior selections in an editable combo box.
Thoughts?
- Konstantin