Sachin, can you translate this from eclipse speak to geronimo speak?
-dain
On Mar 1, 2006, at 1:23 PM, Sachin Patel wrote:
Please respond with any comments or concerns you have with this
second proposal as it will have a direct affect on G tooling.
- sachin
Begin forwarded message:
From: "Konstantin Komissarchik" <[EMAIL PROTECTED]>
Date: March 1, 2006 4:02:33 PM EST
To: "General discussion of project-wide or architectural issues."
<[email protected]>
Subject: [wtp-dev] Proposal for Merging Server Runtime and Server
Instance
Reply-To: "General discussion of project-wide or architectural
issues." <[email protected]>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
