Arthur,
I understand and what I am proposing would
in no way restrict this use case. What my proposal does is make all of these
configurations into runtimes. By having access to the full configuration of a
runnable server, we get a far more accurate modeling of the actual capabilities
of the server and that translates into being able to more accurately constrain
the facets the user can select for the project targeting that server/runtime.
Better understanding of the server capabilities translates into fewer surprises
when you go to run your app. Note that this also does not restrict your ability
to publish the same project to multiple servers. Just like right now, projects
would target runtimes and separately projects would be published to servers.
The only difference is that my proposal would make all servers also runtimes.
Hope this clarifies.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Arthur Ryman
Sent: Thursday, March 09, 2006
8:40 AM
To: General
discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Proposal
for Merging Server Runtime and Server Instance
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