Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 21858 invoked from network); 1 Mar 2006 21:22:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Mar 2006 21:22:41 -0000 Received: (qmail 75641 invoked by uid 500); 1 Mar 2006 21:23:25 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 75598 invoked by uid 500); 1 Mar 2006 21:23:25 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 75587 invoked by uid 99); 1 Mar 2006 21:23:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 13:23:25 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=HTML_MESSAGE,RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [206.190.53.28] (HELO smtp103.plus.mail.re2.yahoo.com) (206.190.53.28) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 01 Mar 2006 13:23:23 -0800 Received: (qmail 44407 invoked from network); 1 Mar 2006 21:23:00 -0000 Received: from unknown (HELO ?9.37.214.137?) (spalias78@129.33.49.251 with plain) by smtp103.plus.mail.re2.yahoo.com with SMTP; 1 Mar 2006 21:23:00 -0000 Mime-Version: 1.0 (Apple Message framework v746.2) To: dev@geronimo.apache.org Message-Id: <20CA2D06-450A-439D-B618-426D31A728D3@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17--267762902 References: <99479F4D39C9244F8E17E688193A3DD80CC6D7@repbex02.amer.bea.com> From: Sachin Patel Subject: Fwd: [wtp-dev] Proposal for Merging Server Runtime and Server Instance Date: Wed, 1 Mar 2006 16:23:14 -0500 X-Mailer: Apple Mail (2.746.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-17--267762902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed 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" > Date: March 1, 2006 4:02:33 PM EST > To: "General discussion of project-wide or architectural issues." =20 > > Subject: [wtp-dev] Proposal for Merging Server Runtime and Server =20 > Instance > Reply-To: "General discussion of project-wide or architectural =20 > issues." > > 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 in =20= > others. In particular: > > > > The runtime is supposed to be a full description of the server, =20 > including its capabilities (which facets are supported). While that =20= > is true in some cases, often the actual server configuration is =20 > necessary in order to get the complete understanding of what=92s =20 > supported. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D111545 =20= > 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 created =20= > runtime would not be a server, but if the user also provides the =20 > domain configuration directory, then the runtime becomes a =20 > startable server. A project can be targeted to either one for =20 > development, but only the latter one can be used to run/debug the =20 > app. This approach places a lot of flexibility in the hands of the =20 > runtime providers. It=92s conceivable that some may even allow a =20 > runtime that=92s not a server to be =93converted=94 into a server by =20= > 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 servers =20= > with decorations and additional actions, such as start, stop, and =20 > status monitoring. This would replace the dedicated 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. The =20= > above proposal leaves this in the hands of runtime providers. If =20 > creating a server instance configuration is not trivial, the new =20 > runtime wizard should let the user opt out of that. The end result =20 > would be an un-runnable runtime that the user can still develop =20 > 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, copyrighted =20 > and/or > legally privileged, and is intended solely for the use of the =20 > individual > or entity named in this message. If you are not the intended =20 > recipient, > and have received this message in error, please immediately return =20 > this > by email and then delete it. > _______________________________________________ > wtp-dev mailing list > wtp-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/wtp-dev --Apple-Mail-17--267762902 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Please respond with any comments = or concerns you have with this 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." <wtp-dev@eclipse.org>
Subject: = [wtp-dev] Proposal for Merging Server Runtime and Server = Instance
Reply-To: "General discussion of project-wide or = architectural issues." <wtp-dev@eclipse.org>

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=92s has = turned out to be in a problem in others. In = particular:

=A0

  • 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=92s supported. See https://bu= gs.eclipse.org/bugs/show_bug.cgi?id=3D111545 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.
    • =

=A0

I=92d 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=92s 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=92s 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=92s conceivable = that some may even allow a runtime that=92s not a server to be = =93converted=94 into a server by specifying additional = information.

=A0

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.

=A0

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.

=A0

So how would we handle use = cases that drove to the separation of the runtime and the = server?

=A0

  1. I want to just write code. = I haven=92t created a server and I don=92t 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=92t 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.

=A0

Thoughts?

=A0

- 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
=

= --Apple-Mail-17--267762902--