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.
