Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <20CA2D06-450A-439D-B618-426D31A728D3@gmail.com>
References: <99479F4D39C9244F8E17E688193A3DD80CC6D7@repbex02.amer.bea.com>
 <20CA2D06-450A-439D-B618-426D31A728D3@gmail.com>
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <3E12B049-B7D1-4988-8530-E93971AA6B7B@iq80.com>
Content-Transfer-Encoding: quoted-printable
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Date: Wed, 1 Mar 2006 14:35:04 -0800
To: dev@geronimo.apache.org

Sachin, can you translate this from eclipse speak to geronimo speak?

-dain

On Mar 1, 2006, at 1:23 PM, Sachin Patel wrote:

> Please respond with any comments or concerns you have with this =20
> second proposal as it will have a direct affect on G tooling.
>
> - sachin
>
>
>
> Begin forwarded message:
>
>> From: "Konstantin Komissarchik" <kosta@bea.com>
>> Date: March 1, 2006 4:02:33 PM EST
>> To: "General discussion of project-wide or architectural issues." =20
>> <wtp-dev@eclipse.org>
>> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server =20
>> Instance
>> Reply-To: "General discussion of project-wide or architectural =20
>> issues." <wtp-dev@eclipse.org>
>>
>> Currently the server tools framework has a separate notion of =20
>> runtime and a server. Typically, the runtime is supposed to =20
>> represent the server install location, while server instance =20
>> supposed to represent an actual runnable server configuration. The =20=

>> runtime then functions almost like a factory for server instances. =20=

>> You can have any number (including zero) of server instances =20
>> associated with a runtime. While that separation can be a good =20
>> thing in some situations, it=92s has turned out to be in a problem =20=

>> in others. In particular:
>>
>>
>>
>> The runtime is supposed to be a full description of the server, =20
>> including its capabilities (which facets are supported). While =20
>> that is true in some cases, often the actual server configuration =20
>> is necessary in order to get the complete understanding of what=92s =20=

>> supported. See https://bugs.eclipse.org/bugs/show_bug.cgi?=20
>> id=3D111545 for one example of this.
>> Having to create and maintain separate lists of runtimes and =20
>> servers has shown to be confusing for users. Extra steps are =20
>> necessary. The user has to know about the preferences page for =20
>> managing runtimes and the servers view for managing servers. Often =20=

>> there is confusion as to which one you are talking about. People =20
>> use terms server and runtime interchangeably, etc.
>> Some runtimes (such as Tomcat) do not have additional server =20
>> configuration, in which case the extra step of creating a server =20
>> from a runtime is very unnecessary.
>>
>>
>> I=92d like to propose that the server runtime and server instance be =20=

>> merged into one. I believe we can do that without detriment to the =20=

>> use cases that gave rise to the separation. We can do that by =20
>> allowing a runtime to also (optionally) be a server. That is, all =20
>> servers would be runtimes, but not all runtimes would be servers. =20
>> When creating a runtime via the new runtime wizard, the runtime =20
>> provider will have full flexibility in determining whether the =20
>> runtime that=92s created is a server or not. Some runtime providers =20=

>> (such as Tomcat) may always create servers. Others, such WebLogic, =20=

>> may do that optionally based on user=92s input. For instance, if the =20=

>> user specifies just the WebLogic install location, then the =20
>> created runtime would not be a server, but if the user also =20
>> provides the domain configuration directory, then the runtime =20
>> becomes a startable server. A project can be targeted to either =20
>> one for development, but only the latter one can be used to run/=20
>> debug the app. This approach places a lot of flexibility in the =20
>> hands of the runtime providers. It=92s conceivable that some may =20
>> even allow a runtime that=92s not a server to be =93converted=94 into =
a =20
>> server by specifying additional information.
>>
>>
>>
>> The users would manage the list of runtimes via a new Runtimes =20
>> workbench view. The view would be extensible, allowing the server =20
>> tools framework to plug in and mark those runtimes that are =20
>> servers with decorations and additional actions, such as start, =20
>> stop, and status monitoring. This would replace the dedicated =20
>> Servers view.
>>
>>
>>
>> At the api level, IRuntime would be adaptable to IServer (as =20
>> applicable) and IServer would be adaptable to IRuntime (always). =20
>> The server tools would maintain the markers that indicate which =20
>> runtimes are servers and surface this via api for use by the =20
>> 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 =20
>> the runtime and the server?
>>
>>
>>
>> I want to just write code. I haven=92t created a server and I don=92t =
=20
>> want to create one. I will worry about running/debugging later. =20
>> The above proposal leaves this in the hands of runtime providers. =20
>> If creating a server instance configuration is not trivial, the =20
>> new runtime wizard should let the user opt out of that. The end =20
>> result would be an un-runnable runtime that the user can still =20
>> develop against.
>> I don=92t want to have to specify the location of my server install =20=

>> every time I create a new server instance. This can easily be =20
>> handled in the runtime creation wizards by remembering the prior =20
>> selections in an editable combo box.
>>
>>
>> Thoughts?
>>
>>
>>
>> - Konstantin
>>
>> _____________________________________________________________________=20=

>> __ Notice: This email message, together with any attachments, may =20
>> contain information of BEA Systems, Inc., its subsidiaries and =20
>> affiliated entities, that may be confidential, proprietary, =20
>> copyrighted and/or legally privileged, and is intended solely for =20
>> the use of the individual or entity named in this message. If you =20
>> are not the intended recipient, and have received this message in =20
>> error, please immediately return this by email and then delete it.
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>