| RE: [wtp-dev] Proposal for Merging Server Runtime and Server Instance |
|
So I see three broad functions of a runtime
implementation, not all of which are required of course: 1) filter for project
creation/configuration 2) project classpath provider 3) configuring run/debug I agree that users would be well served if
the various runtime wizards and the runtime preferences panels better linked/integrated
#3 with #1 & #2. For runtimes such as Tomcat and JBoss, there may be
no reason to have a separate “New Server” wizard – i.e. adding
a new runtime definition automatically results in a new node in Servers view,
and there’s no UI for adding additional servers corresponding to that
runtime definition. However, I have two reservations about the
proposal. 1) I think Servers view should continue to
be strictly for testing/debugging purposes. I think trying to add
management of non-runnable runtime nodes would be confusing and unnecessary - the
preferences dialog runtime list seems sufficient. 2) I don’t think WTP API (or UI) needs
to, or should, assume there will always be either a one-to-one or one-to-zero
relationship between “runtime type” and “runnable server”.
If a particular vendor wishes to implement a one-to-many user experience, the api
should not inhibit it. -Ted From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik 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:
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?
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. _______________________________________________________________________ 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. |