You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Sachin Patel <sp...@gmail.com> on 2006/03/01 22:23:14 UTC
Fwd: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
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" <ko...@bea.com>
> Date: March 1, 2006 4:02:33 PM EST
> To: "General discussion of project-wide or architectural issues."
> <wt...@eclipse.org>
> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server
> Instance
> Reply-To: "General discussion of project-wide or architectural
> issues." <wt...@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’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 https://bugs.eclipse.org/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
> wtp-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Posted by Sachin Patel <sp...@gmail.com>.
I think it will simplify things greatly from a users perspective so
I'm all for it. It will also give us a whole lot more flexibility.
We'll be able to create the server instance when the runtime is
created so that means less user input. Also we currently add the
entire runtime to every project type and if G is headed toward a
componetized model it only makes sense to define a set of components
in our "runtime" definition. It will be really cool to be able to be
able to inform the user of a server instances capabilties before they
create a project.
- sachin
On Mar 1, 2006, at 7:54 PM, Dain Sundstrom wrote:
> 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.
>
> -dain
>
> 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".
>>
>> RUNTIMES & SERVERS
>> ----------------
>> 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
>> ------
>> 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" <ko...@bea.com>
>>>>> Date: March 1, 2006 4:02:33 PM EST
>>>>> To: "General discussion of project-wide or architectural
>>>>> issues." <wt...@eclipse.org>
>>>>> Subject: [wtp-dev] Proposal for Merging Server Runtime and
>>>>> Server Instance
>>>>> Reply-To: "General discussion of project-wide or architectural
>>>>> issues." <wt...@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’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 https://bugs.eclipse.org/
>>>>> 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
>>>>> wtp-dev@eclipse.org
>>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>>
>>>
>>
>
Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Posted by Dain Sundstrom <da...@iq80.com>.
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.
-dain
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".
>
> RUNTIMES & SERVERS
> ----------------
> 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
> ------
> 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" <ko...@bea.com>
>>>> Date: March 1, 2006 4:02:33 PM EST
>>>> To: "General discussion of project-wide or architectural
>>>> issues." <wt...@eclipse.org>
>>>> Subject: [wtp-dev] Proposal for Merging Server Runtime and
>>>> Server Instance
>>>> Reply-To: "General discussion of project-wide or architectural
>>>> issues." <wt...@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’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 https://bugs.eclipse.org/
>>>> 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
>>>> wtp-dev@eclipse.org
>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>
>>
>
RE: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Posted by Lin Sun <li...@gmail.com>.
With this change, could you go over a user case where user would
develop/test his J2EE application locally first then deploy it to the remote
production server? I could not think of how to tie the runtime and server
together in remote deployment environment.
Thanks,
Lin
-----Original Message-----
From: Sachin Patel [mailto:sppatel2@gmail.com]
Sent: Wednesday, March 01, 2006 7:34 PM
To: dev@geronimo.apache.org
Subject: Re: [wtp-dev] Proposal for Merging Server Runtime and Server
Instance
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".
RUNTIMES & SERVERS
----------------
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
------
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" <ko...@bea.com>
>>> Date: March 1, 2006 4:02:33 PM EST
>>> To: "General discussion of project-wide or architectural issues."
>>> <wt...@eclipse.org>
>>> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server
>>> Instance
>>> Reply-To: "General discussion of project-wide or architectural
>>> issues." <wt...@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'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 https://bugs.eclipse.org/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
>>> wtp-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>
Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Posted by Sachin Patel <sp...@gmail.com>.
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".
RUNTIMES & SERVERS
----------------
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
------
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" <ko...@bea.com>
>>> Date: March 1, 2006 4:02:33 PM EST
>>> To: "General discussion of project-wide or architectural issues."
>>> <wt...@eclipse.org>
>>> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server
>>> Instance
>>> Reply-To: "General discussion of project-wide or architectural
>>> issues." <wt...@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’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 https://bugs.eclipse.org/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
>>> wtp-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>
Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
Posted by Dain Sundstrom <da...@iq80.com>.
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" <ko...@bea.com>
>> Date: March 1, 2006 4:02:33 PM EST
>> To: "General discussion of project-wide or architectural issues."
>> <wt...@eclipse.org>
>> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server
>> Instance
>> Reply-To: "General discussion of project-wide or architectural
>> issues." <wt...@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’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 https://bugs.eclipse.org/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
>> wtp-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>