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 Thu, 02 Mar 2006 00:54:31 GMT
The proposal sounds good to me, but I don't think I'm really  
qualified to pass any real judgment on tooling.  I would like to know  
what you think of the proposal.  I'd also like to know if it adds  
extra constraints to the Geronimo server.


On Mar 1, 2006, at 4:34 PM, Sachin Patel wrote:

> So hopefully this will make sense... :)
> In the two proposal notes I sent, the discussion is around the 3  
> concepts in WTP, "runtimes", "servers", and "facets" and what we  
> can do to improve the definition, design and interaction between  
> the frameworks that these concepts represent.  So for those not  
> familiar with WTP, let me start by describing these concepts from a  
> "users perspective".
> ----------------
> So currently WTP has a notion of defining a "runtime" and defining  
> a "server".  So for a user wanting to create a j2ee app using WTP  
> and deploy it to geronimo the user must perform currently two  
> distinct tasks.  (1) Is to define a Geronimo runtime using a wizard  
> which asks the location of the runtime which you would point to a  
> geronimo installation.  During project creation you would choose  
> this newly defined runtime and what this essentially does is  
> configures the project to add a JRE and a "runtime classpath  
> container" which contains all of the geronimo spec jars + other G  
> jars.  This means that this project is "targeted" to be deployed to  
> geronimo.
> Now in order to deploy that application, the user currently has to  
> perform a second task, and that is to define and point to the  
> actual server instance.  You may immediatly ask yourself, didn't I  
> just do that by defining the runtime?
> This is currently confusing to users, as the note below indicates.   
> Not only are the definition of the terms confusing in discussions  
> as many times there are used interchangably, but from a users  
> perspective they need to manage in the UI both the list of servers  
> and runtimes and the mapping between the two.  And most of all what  
> is confusing in the above case, both the runtime and the server are  
> pointing to the same thing!  This usability needs to change.  So  
> one of the proposals is for these two to be merged togather, with  
> all server instances being runtimes, but not vise versa.  Runtimes  
> may or may not represent a server instance.  (Multiple server  
> instances may have unique configuration/launching data in distinct  
> location but share the same runtime jars.  For example WebSphere  
> has a concept of profiles).
> So with that re-read below and hopefully the note will make more  
> sense.
> ------
> Facets are basically a unit of function that can be applied and  
> removed to a given WTP project.  For example, if a user is wanting  
> to create a "Web Project" the "web facet" is selected and this  
> creates the project directory structure specific for a web project,  
> web.xml, etc.... So how do facets relate to geronimo runtimes and  
> servers?
> Since G is headed toward a model where a user can produce a custom  
> server image (i.e web container only, no j2ee, etc...) each  
> distribution may be different.  So after defining a runtime by  
> pointing to this installation, some facets may or not be applicable  
> to add on a project.  So from a tooling perspective we should be  
> able to ask...Given this "runtime" what kind of capabilties do I  
> have? What kind of projects can I create?
> Now the second use case is that a user may not be interested in  
> deploying his app yet and only concerned is developing a project  
> that would be supported geronimo.  So they may or may not have a  
> local geronimo install image.  So with our integration and use of  
> maven, we should be able to take a more appcentric approach in the  
> tools as well.  So the user should be able to simply choose the ejb  
> project creation wizard, select geronimo, and we should be able to  
> dynamically generate the minimum runtime for that project by  
> pulling in the necessary jars from their local install or from a  
> maven repo.
> I hope that helps.
> - sachin
> On Mar 1, 2006, at 5:35 PM, Dain Sundstrom wrote:
>> 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  
>>> 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 
>>>> 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?
>>>> 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