I am not real sure what you are referring to
by “the list of projects deployed to the server”.
Currently we have a runtime that
essentially represents a server install location. Some servers require additional
configuration files before a server instance can be started. This is being
called the server. There is one to many relationship between the server install
location (runtime) and the runnable server configuration (server).
This proposal seeks to merge the two for
the reasons stated. The unified list of runnable and non-runnable runtimes
might look like this:
My Tomcat (points to the tomcat dir) –
runnable as tomcat does not require further configuration
WebLogic 1 (points to the weblogic install
dir) – not runnable; requires an additional pointer to the domain
configuration directory
WebLogic 2 (points to the weblogic install
dir and domain directory) – runnable
The UI would mark the runnable ones as “servers”.
There would be menu actions for starting, stopping, associating projects for
deployment, etc.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Arthur Ryman
Sent: Wednesday, March 08, 2006
3:39 PM
To: General
discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Proposal
for Merging Server Runtime and Server Instance
Kosta,
Is
what you are calling a runable server configuration the list of projects
deployed to the server? If so, I think it is confusing to combine them since
there is a one to many relation between installation locations and project
configurations.
However,
I agree that we should make life easy for developers who don't want to know
about servers. Perhaps the New Server Runtime wizard should optionally create a
configuration.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
"Konstantin
Komissarchik" <kosta@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
03/01/2006 04:02 PM
Please
respond to
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General
discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[wtp-dev] Proposal for Merging Server Runtime
and Server Instance
|
|
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?
1.
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.
2.
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