geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Fwd: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Date Wed, 01 Mar 2006 21:23:14 GMT
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" <>
> Date: March 1, 2006 4:02:33 PM EST
> To: "General discussion of project-wide or architectural issues."  
> <>
> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server  
> Instance
> Reply-To: "General discussion of project-wide or architectural  
> issues." <>
> 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  
> 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?
> 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.
> 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

View raw message