The runtime provider would define as many
runtime components as needed to accurately model all of their server’s available
capabilities. Then, when the new runtime wizard runs, the runtime provider would
configure the runtime definition with the appropriate runtime components for
that server’s actual capabilities. The runtime definition (along with the
list of specified runtime components) would then be stored in the workspace
metadata. We can also make the generation of the runtime components list be
more dynamic, but that comes with a price of forcing early loading of the
runtime provider’s plugin containing the delegate class...
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Marshall Culpepper
Sent: Wednesday, March 01, 2006
1:59 PM
To: General
discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Proposal
for Merging Server Runtime and Server Instance
+1
How would runtime components (from your last proposal) tie together with the
various server capabilities?
On 3/1/06, Konstantin
Komissarchik < kosta@xxxxxxx>
wrote:
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
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
--
Marshall Culpepper
marshall.culpepper@xxxxxxxxx
JBoss Eclipse IDE Lead, JBoss Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
|