Konstantin,
The server configuration contains things like port numbers, but also the
list of Web apps (the list of projects deployed to the server). You
might want to have several different configurations for a single server,
or even run the same code in multiple processes using different
configurations.
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/08/2006 07:06 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
RE: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
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
_______________________________________________________________________
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
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev