Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance

[Arthur Ryman <ryman@xxxxxxxxxx>]

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