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

[David.Brandow@xxxxxxxxxx]

I would tend to agree with the concept
behind this proposal, but I think there's like a compromise solution.  In
this sort of situation, its my belief that you should have a built-in set
of "drivers", if you will, which the user can edit/extend that
contain common server definitions.  When the user goes to create a
specific server instance, they can choose to get the connection values
pre-filled in by using an existing server runtime or can fill them all
in manually.  So in concrete terms, you would still have the list
of server runtimes, but you wouldn't have to have a server runtime in order
to create a server instance, it would just make your life a little easier
if you did have one.  Best of both worlds.  Anyway, just a suggestion.

-----------------------------------------------
Keep your stick on the ice,

David Brandow
Sybase EAServer Engineering

----- Forwarded by Jean
Choi/SYBASE on 03/09/2006 10:25 AM -----

Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

03/08/2006 03:38 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

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_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev