You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/10/31 03:55:18 UTC
Remote Deployment
So I think the strategy for remote deployment is to create a servlet
to accept file uploads, so we can stream the application/module
archive to the servlet and it will save it to the server filesystem,
and then we can issue the normal commands where the server expects the
files to be on the local filesystem.
The only question then is how the deploy tool should locate the servlet.
We now have the capability to construct an accurate URL to a web
application (no matter how many containers are running). I assume
we'd put this servlet in the console web app for now, rather than
create a whole new web app just for supporting remote deployment.
Which makes the question, how can the server-side of the JSR-88
plumbing figure out which module contains the/a running console?
I'm thinking of doing something cheesy, like adding an empty GBean to
the console module, and then having the JSR-88 plumbing do a gbean
query to locate that GBean, then from there use the dependency manager
to figure out what Configuration it's in, and use that to find the web
module and construct the URL.
Anyone have a better idea?
Thanks,
Aaron
Re: Remote Deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/1/05, Dain Sundstrom <da...@iq80.com> wrote:
> Guys, I think we are getting a little to far ahead of Aaron's
> proposal. Having a servlet to do remote deployment would be a huge
> step forward for Geronimo, given that remote deployment currently
> doesn't work. Sure in the future it would be nice to support remote
> deployment with out requiring a web container and more granulized
> update support, but for now how about get the basics working?
Right -- the challenge is the same regardless of what application it
ends up in. But my intention is to support deployment from anything
that can speak JSR-88, be it command-line, IDE, etc.
> Why does the console have a different name in Tomcat and Jetty?
I assume so it can be deployed to both at the same time. But the
truth is, I'm not sure, I wasn't the one who made it that way. :)
> Also, will this be a pure http(s) deployment tool or will the tool
> use both the JMX-RMI and http(s) protocols? I would prefer a pure
> http client so it can work in the maximum environments?
Well... That's possible too but it would make the servlet more
complex. I'd prefer to start by running everything the way we do
right now except for offloading the file upload. After that, we can
try to put the rest of the protocol into HTTP(s). For what it's
worth, any of these changes should be invisible to a JSR-88 client,
save perhaps some change to the connect URL.
Aaron
> On Nov 1, 2005, at 6:53 AM, Sachin Patel wrote:
>
> > Please keep in mind the tooling scenarios for this as well.
> >
> > I would eventually like like to see some type of granulized update
> > support. For example, if a user is developing a large application
> > and testing on a remote server, if a single file in a module is
> > changed, it would be quite an overhead for the entire application
> > to have to be repackaged and sent over the network. We need to
> > think about being able to send partial updates to a remote server.
> >
> > Sachin
> >
> > Joe Bohn wrote:
> >
> >> +1
> >> I was thinking the same thing. If implemented as a servlet it
> >> should be independent of the console. What is used for local
> >> deploy should be the same as remote deploy.
> >> Joe
> >> Dave Colasurdo wrote:
> >>
> >>>
> >>>
> >>> Aaron Mulder wrote:
> >>>
> >>>
> >>>>
> >>>> Forget about multiple web containers. The issue is, I know
> >>>> there's a
> >>>> servlet o.a.g.RemoteDeployerServlet running in some web app in
> >>>> Geronimo. What is the URL to contact it? To start with, you
> >>>> need to
> >>>> determine which web application it's in (since we already use
> >>>> different names for the console for Jetty/Tomcat you can't just
> >>>> hardcode a name), and then you need to determine what the URL is to
> >>>> access that web application, which means inspecting its list of
> >>>> connectors.
> >>>>
> >>>>
> >>>
> >>> Is remote deployment unique to the web console? Shouldn't remote
> >>> deployment also be possible from the command line or
> >>> programatically via JMX. Projects/products that embed Geronimo
> >>> may wish to remove the web console altogether in an attempt to
> >>> use G as a hidden embedded server for their application with only
> >>> their preset configurations.
> >>>
> >>> Perhaps a new non-webcontainer specific ( not specific to jetty
> >>> or tomcat) file transfer web application that is not tied to the
> >>> console should be created.
> >>>
> >>>
> >
>
>
Re: Remote Deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/1/05, Dave Colasurdo <da...@earthlink.net> wrote:
> I agree that a simple servlet is a step in the right direction. My
> point was that the servlet shouldn't be part of the web console
> application but rather a different new "file transfer" application that
> contains this one servlet. This avoids the problem of having to figure
> out which web console (jetty or tomcat) to use.
No it doesn't. It just changes the problem to which "file transfer"
application (Jetty or Tomcat) to use.
Also, even if there was only one, the problem is the same -- without
hardcoding the app name, how can the deployment plumbing find out
which application is hosting the servlet it needs? And even if the
name was hardcoded, how do you determine which web container it's
running in and which ports the web container is listening on? (I
think we're much closer to having solutions for those issues, though.)
So far, I'm still planning to use an empty GBean as a token and start
by figuring out what app is hosting that GBean and then what container
that app is in and then what connectors are available for that
container. I will be content to hardcode the URL mapping for the
servlet within the application.
Thanks,
Aaron
> It also allows for
> reuse of the servlet when the console isn't present.
> -Dave-
>
> Dain Sundstrom wrote:
> > Guys, I think we are getting a little to far ahead of Aaron's
> > proposal. Having a servlet to do remote deployment would be a huge
> > step forward for Geronimo, given that remote deployment currently
> > doesn't work. Sure in the future it would be nice to support remote
> > deployment with out requiring a web container and more granulized
> > update support, but for now how about get the basics working?
> >
> > Aaron,
> >
> > Why does the console have a different name in Tomcat and Jetty? Also,
> > will this be a pure http(s) deployment tool or will the tool use both
> > the JMX-RMI and http(s) protocols? I would prefer a pure http client
> > so it can work in the maximum environments?
> >
> > -dain
> >
> > On Nov 1, 2005, at 6:53 AM, Sachin Patel wrote:
> >
> >> Please keep in mind the tooling scenarios for this as well.
> >>
> >> I would eventually like like to see some type of granulized update
> >> support. For example, if a user is developing a large application
> >> and testing on a remote server, if a single file in a module is
> >> changed, it would be quite an overhead for the entire application to
> >> have to be repackaged and sent over the network. We need to think
> >> about being able to send partial updates to a remote server.
> >>
> >> Sachin
> >>
> >> Joe Bohn wrote:
> >>
> >>> +1
> >>> I was thinking the same thing. If implemented as a servlet it
> >>> should be independent of the console. What is used for local
> >>> deploy should be the same as remote deploy.
> >>> Joe
> >>> Dave Colasurdo wrote:
> >>>
> >>>>
> >>>>
> >>>> Aaron Mulder wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> Forget about multiple web containers. The issue is, I know there's a
> >>>>> servlet o.a.g.RemoteDeployerServlet running in some web app in
> >>>>> Geronimo. What is the URL to contact it? To start with, you need to
> >>>>> determine which web application it's in (since we already use
> >>>>> different names for the console for Jetty/Tomcat you can't just
> >>>>> hardcode a name), and then you need to determine what the URL is to
> >>>>> access that web application, which means inspecting its list of
> >>>>> connectors.
> >>>>>
> >>>>>
> >>>>
> >>>> Is remote deployment unique to the web console? Shouldn't remote
> >>>> deployment also be possible from the command line or
> >>>> programatically via JMX. Projects/products that embed Geronimo may
> >>>> wish to remove the web console altogether in an attempt to use G as
> >>>> a hidden embedded server for their application with only their
> >>>> preset configurations.
> >>>>
> >>>> Perhaps a new non-webcontainer specific ( not specific to jetty or
> >>>> tomcat) file transfer web application that is not tied to the
> >>>> console should be created.
> >>>>
> >>>>
> >>
> >
> >
> >
>
Re: Remote Deployment
Posted by Dave Colasurdo <da...@earthlink.net>.
I agree that a simple servlet is a step in the right direction. My
point was that the servlet shouldn't be part of the web console
application but rather a different new "file transfer" application that
contains this one servlet. This avoids the problem of having to figure
out which web console (jetty or tomcat) to use. It also allows for
reuse of the servlet when the console isn't present.
-Dave-
Dain Sundstrom wrote:
> Guys, I think we are getting a little to far ahead of Aaron's
> proposal. Having a servlet to do remote deployment would be a huge
> step forward for Geronimo, given that remote deployment currently
> doesn't work. Sure in the future it would be nice to support remote
> deployment with out requiring a web container and more granulized
> update support, but for now how about get the basics working?
>
> Aaron,
>
> Why does the console have a different name in Tomcat and Jetty? Also,
> will this be a pure http(s) deployment tool or will the tool use both
> the JMX-RMI and http(s) protocols? I would prefer a pure http client
> so it can work in the maximum environments?
>
> -dain
>
> On Nov 1, 2005, at 6:53 AM, Sachin Patel wrote:
>
>> Please keep in mind the tooling scenarios for this as well.
>>
>> I would eventually like like to see some type of granulized update
>> support. For example, if a user is developing a large application
>> and testing on a remote server, if a single file in a module is
>> changed, it would be quite an overhead for the entire application to
>> have to be repackaged and sent over the network. We need to think
>> about being able to send partial updates to a remote server.
>>
>> Sachin
>>
>> Joe Bohn wrote:
>>
>>> +1
>>> I was thinking the same thing. If implemented as a servlet it
>>> should be independent of the console. What is used for local
>>> deploy should be the same as remote deploy.
>>> Joe
>>> Dave Colasurdo wrote:
>>>
>>>>
>>>>
>>>> Aaron Mulder wrote:
>>>>
>>>>
>>>>>
>>>>> Forget about multiple web containers. The issue is, I know there's a
>>>>> servlet o.a.g.RemoteDeployerServlet running in some web app in
>>>>> Geronimo. What is the URL to contact it? To start with, you need to
>>>>> determine which web application it's in (since we already use
>>>>> different names for the console for Jetty/Tomcat you can't just
>>>>> hardcode a name), and then you need to determine what the URL is to
>>>>> access that web application, which means inspecting its list of
>>>>> connectors.
>>>>>
>>>>>
>>>>
>>>> Is remote deployment unique to the web console? Shouldn't remote
>>>> deployment also be possible from the command line or
>>>> programatically via JMX. Projects/products that embed Geronimo may
>>>> wish to remove the web console altogether in an attempt to use G as
>>>> a hidden embedded server for their application with only their
>>>> preset configurations.
>>>>
>>>> Perhaps a new non-webcontainer specific ( not specific to jetty or
>>>> tomcat) file transfer web application that is not tied to the
>>>> console should be created.
>>>>
>>>>
>>
>
>
>
Re: Remote Deployment
Posted by Dain Sundstrom <da...@iq80.com>.
Guys, I think we are getting a little to far ahead of Aaron's
proposal. Having a servlet to do remote deployment would be a huge
step forward for Geronimo, given that remote deployment currently
doesn't work. Sure in the future it would be nice to support remote
deployment with out requiring a web container and more granulized
update support, but for now how about get the basics working?
Aaron,
Why does the console have a different name in Tomcat and Jetty?
Also, will this be a pure http(s) deployment tool or will the tool
use both the JMX-RMI and http(s) protocols? I would prefer a pure
http client so it can work in the maximum environments?
-dain
On Nov 1, 2005, at 6:53 AM, Sachin Patel wrote:
> Please keep in mind the tooling scenarios for this as well.
>
> I would eventually like like to see some type of granulized update
> support. For example, if a user is developing a large application
> and testing on a remote server, if a single file in a module is
> changed, it would be quite an overhead for the entire application
> to have to be repackaged and sent over the network. We need to
> think about being able to send partial updates to a remote server.
>
> Sachin
>
> Joe Bohn wrote:
>
>> +1
>> I was thinking the same thing. If implemented as a servlet it
>> should be independent of the console. What is used for local
>> deploy should be the same as remote deploy.
>> Joe
>> Dave Colasurdo wrote:
>>
>>>
>>>
>>> Aaron Mulder wrote:
>>>
>>>
>>>>
>>>> Forget about multiple web containers. The issue is, I know
>>>> there's a
>>>> servlet o.a.g.RemoteDeployerServlet running in some web app in
>>>> Geronimo. What is the URL to contact it? To start with, you
>>>> need to
>>>> determine which web application it's in (since we already use
>>>> different names for the console for Jetty/Tomcat you can't just
>>>> hardcode a name), and then you need to determine what the URL is to
>>>> access that web application, which means inspecting its list of
>>>> connectors.
>>>>
>>>>
>>>
>>> Is remote deployment unique to the web console? Shouldn't remote
>>> deployment also be possible from the command line or
>>> programatically via JMX. Projects/products that embed Geronimo
>>> may wish to remove the web console altogether in an attempt to
>>> use G as a hidden embedded server for their application with only
>>> their preset configurations.
>>>
>>> Perhaps a new non-webcontainer specific ( not specific to jetty
>>> or tomcat) file transfer web application that is not tied to the
>>> console should be created.
>>>
>>>
>
Re: Remote Deployment
Posted by Sachin Patel <sp...@gmail.com>.
Please keep in mind the tooling scenarios for this as well.
I would eventually like like to see some type of granulized update
support. For example, if a user is developing a large application and
testing on a remote server, if a single file in a module is changed, it
would be quite an overhead for the entire application to have to be
repackaged and sent over the network. We need to think about being able
to send partial updates to a remote server.
Sachin
Joe Bohn wrote:
> +1
> I was thinking the same thing. If implemented as a servlet it should be
> independent of the console. What is used for local deploy should be
> the same as remote deploy.
>
> Joe
>
> Dave Colasurdo wrote:
>>
>>
>> Aaron Mulder wrote:
>>
>>>
>>> Forget about multiple web containers. The issue is, I know there's a
>>> servlet o.a.g.RemoteDeployerServlet running in some web app in
>>> Geronimo. What is the URL to contact it? To start with, you need to
>>> determine which web application it's in (since we already use
>>> different names for the console for Jetty/Tomcat you can't just
>>> hardcode a name), and then you need to determine what the URL is to
>>> access that web application, which means inspecting its list of
>>> connectors.
>>>
>>
>> Is remote deployment unique to the web console? Shouldn't remote
>> deployment also be possible from the command line or programatically
>> via JMX. Projects/products that embed Geronimo may wish to remove the
>> web console altogether in an attempt to use G as a hidden embedded
>> server for their application with only their preset configurations.
>>
>> Perhaps a new non-webcontainer specific ( not specific to jetty or
>> tomcat) file transfer web application that is not tied to the console
>> should be created.
>>
>>
>
Re: Remote Deployment
Posted by Joe Bohn <jo...@earthlink.net>.
+1
I was thinking the same thing. If implemented as a servlet it should be
independent of the console. What is used for local deploy should be
the same as remote deploy.
Joe
Dave Colasurdo wrote:
>
>
> Aaron Mulder wrote:
>
>>
>> Forget about multiple web containers. The issue is, I know there's a
>> servlet o.a.g.RemoteDeployerServlet running in some web app in
>> Geronimo. What is the URL to contact it? To start with, you need to
>> determine which web application it's in (since we already use
>> different names for the console for Jetty/Tomcat you can't just
>> hardcode a name), and then you need to determine what the URL is to
>> access that web application, which means inspecting its list of
>> connectors.
>>
>
> Is remote deployment unique to the web console? Shouldn't remote
> deployment also be possible from the command line or programatically via
> JMX. Projects/products that embed Geronimo may wish to remove the web
> console altogether in an attempt to use G as a hidden embedded server
> for their application with only their preset configurations.
>
> Perhaps a new non-webcontainer specific ( not specific to jetty or
> tomcat) file transfer web application that is not tied to the console
> should be created.
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: Remote Deployment
Posted by Dave Colasurdo <da...@earthlink.net>.
Aaron Mulder wrote:
>
> Forget about multiple web containers. The issue is, I know there's a
> servlet o.a.g.RemoteDeployerServlet running in some web app in
> Geronimo. What is the URL to contact it? To start with, you need to
> determine which web application it's in (since we already use
> different names for the console for Jetty/Tomcat you can't just
> hardcode a name), and then you need to determine what the URL is to
> access that web application, which means inspecting its list of
> connectors.
>
Is remote deployment unique to the web console? Shouldn't remote
deployment also be possible from the command line or programatically via
JMX. Projects/products that embed Geronimo may wish to remove the web
console altogether in an attempt to use G as a hidden embedded server
for their application with only their preset configurations.
Perhaps a new non-webcontainer specific ( not specific to jetty or
tomcat) file transfer web application that is not tied to the console
should be created.
Re: Remote Deployment
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 10/30/05, Matt Hogstrom <ma...@hogstrom.org> wrote:
> Are you referring to the situation when multiple Web Containers are running in
> the server and the console is running in only one of them? Is this a scenario
> that you've seen users requesting? I think more than one web container in a
> user deployment (apart from server development) is an unlikely scenario. I'm
> open to it but I haven't seen any demand for it so I'm trying to understand the
> demand.
Forget about multiple web containers. The issue is, I know there's a
servlet o.a.g.RemoteDeployerServlet running in some web app in
Geronimo. What is the URL to contact it? To start with, you need to
determine which web application it's in (since we already use
different names for the console for Jetty/Tomcat you can't just
hardcode a name), and then you need to determine what the URL is to
access that web application, which means inspecting its list of
connectors.
Aaron
> Aaron Mulder wrote:
> > So I think the strategy for remote deployment is to create a servlet
> > to accept file uploads, so we can stream the application/module
> > archive to the servlet and it will save it to the server filesystem,
> > and then we can issue the normal commands where the server expects the
> > files to be on the local filesystem.
> >
> > The only question then is how the deploy tool should locate the servlet.
> >
> > We now have the capability to construct an accurate URL to a web
> > application (no matter how many containers are running). I assume
> > we'd put this servlet in the console web app for now, rather than
> > create a whole new web app just for supporting remote deployment.
> >
> > Which makes the question, how can the server-side of the JSR-88
> > plumbing figure out which module contains the/a running console?
> >
> > I'm thinking of doing something cheesy, like adding an empty GBean to
> > the console module, and then having the JSR-88 plumbing do a gbean
> > query to locate that GBean, then from there use the dependency manager
> > to figure out what Configuration it's in, and use that to find the web
> > module and construct the URL.
> >
> > Anyone have a better idea?
> >
> > Thanks,
> > Aaron
> >
> >
> >
>
>
Re: Remote Deployment
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Are you referring to the situation when multiple Web Containers are running in
the server and the console is running in only one of them? Is this a scenario
that you've seen users requesting? I think more than one web container in a
user deployment (apart from server development) is an unlikely scenario. I'm
open to it but I haven't seen any demand for it so I'm trying to understand the
demand.
thanks.
Matt
Aaron Mulder wrote:
> So I think the strategy for remote deployment is to create a servlet
> to accept file uploads, so we can stream the application/module
> archive to the servlet and it will save it to the server filesystem,
> and then we can issue the normal commands where the server expects the
> files to be on the local filesystem.
>
> The only question then is how the deploy tool should locate the servlet.
>
> We now have the capability to construct an accurate URL to a web
> application (no matter how many containers are running). I assume
> we'd put this servlet in the console web app for now, rather than
> create a whole new web app just for supporting remote deployment.
>
> Which makes the question, how can the server-side of the JSR-88
> plumbing figure out which module contains the/a running console?
>
> I'm thinking of doing something cheesy, like adding an empty GBean to
> the console module, and then having the JSR-88 plumbing do a gbean
> query to locate that GBean, then from there use the dependency manager
> to figure out what Configuration it's in, and use that to find the web
> module and construct the URL.
>
> Anyone have a better idea?
>
> Thanks,
> Aaron
>
>
>