geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Date Wed, 01 Mar 2006 22:35:04 GMT
Sachin, can you translate this from eclipse speak to geronimo speak?


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

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