You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sam Ewing <ja...@yahoo.com> on 2002/06/14 22:00:25 UTC
Tomcat 4.1/4.0 manager application
I'm facing a few problems with the Tomcat manager
application..
1. In 4.0.4, the install command copies the web app
into the appBase directory.. in 4.1.3, the install
does not do this; however the installed application is
availble for use. After restarting Tomcat 4.1, the
newly installed application is not visible. Am I doing
something wrong here? or is it a bug in 4.1?
2. How do you pass the war file to the 4.1 deploy
command? The documentation says - "Upload the web
application archive (WAR) file that is specified as
the request data in this HTTP PUT ". Umm.. how do I do
this via a browser?
On another train..what is the difference between what
the install and deploy commands do? AFAIK, both seem
to be installing and starting the app..
Thanks!!!
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat 4.1/4.0 manager application
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 14 Jun 2002, Sam Ewing wrote:
> Date: Fri, 14 Jun 2002 23:07:48 -0700 (PDT)
> From: Sam Ewing <ja...@yahoo.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Tomcat 4.1/4.0 manager application
>
> Thanks for all the help Craig. A couple of other
> doubts :-)
>
> 1. In Tomcat 4.1, when a install command is run, how
> is the web application 'installed'. I mean, the
> application is neither copied into webapps, nor a
> Context entry added to server.xml; so how does the
> requests for /new_app (if that is the context path)
> sent to the new application? Is everything manipulated
> in the in memory representation of server.xml?
>
Yes, although technically there isn't really any in-memory representation
of server.xml contents. Instead, there are the actual Tomcat components,
usually one object per XML element in server.xml. For example, there is
an object that implements the org.apache.catalina.Host interface for each
<Host> element in server.xml. Each of these components have JavaBeans
getters and setters that correspond to the configurable properties in
server.xml, so saving server.xml again is primarily an exercise of walking
down the tree of components and creating an XML element for each relevant
one. (The details are somewhat messier than this, but that's the basic
idea.)
An application being installed causes the creation of a new Context object
in memory, with a "docBase" property that points at the absolute path to
your directory or WAR file. The context path for the new app (i.e. the
"path" property) is immediately added to the mapping tables that Tomcat
uses to decide which webapp to give a request to.
By the way, the "deploy" command in 4.1 is similar but different. It
uploads the WAR file, unpacks it into a temporary directory, and does
(essentially) an "install" of that temporary directory.
The adminisration app in 4.1.x already has the ability to save the current
in-memory state of Tomcat's configuration back to server.xml -- it's just
a matter of adding the triggering of this save when install executes.
> 2. In Tomcat 4.0, the remove command doesnt remove the
> installed app from application base.. is that ok since
> the remove in 4.0 is actually an undeploy?
>
I don't think you'll see any major functional changes in 4.0.x any more,
just bugfix releases. Personally, I'm focused on the 4.1.x version's
behavior, since there are tons of new features and performance
improvements.
> 3. In Tomcat 4.0, the install copies the web app into
> the application base.. yet when I restart Tomcat, the
> 'manager list' doesnt show this new webapp, nor does
> is this application accessible. Why is this when the
> application has been unpacked into application base?
>
The only way I can think of for that to happen would be if an error
occurred on your app during the startup -- check the logs. But I don't
use 4.0.x any more, so don't remember any more details.
> Sorry for all the questions!
I'm afraid I can't be of much additional assistance, since I'm not
actively involved in Tomcat development any more (my job roles have
changed, and occupy more than 100% of my time :-).
Craig
>
> --- "Craig R. McClanahan" <cr...@apache.org> wrote:
> >
> >
> > On Fri, 14 Jun 2002, Sam Ewing wrote:
> >
> > > Date: Fri, 14 Jun 2002 13:00:25 -0700 (PDT)
> > > From: Sam Ewing <ja...@yahoo.com>
> > > Reply-To: Tomcat Users List
> > <to...@jakarta.apache.org>
> > > To: tomcat-user@jakarta.apache.org
> > > Subject: Tomcat 4.1/4.0 manager application
> > >
> > > I'm facing a few problems with the Tomcat manager
> > > application..
> > >
> > > 1. In 4.0.4, the install command copies the web
> > app
> > > into the appBase directory.. in 4.1.3, the install
> > > does not do this; however the installed
> > application is
> > > availble for use.
> >
> > This is the correct behavior for the future -- it
> > takes advantage of the
> > fact that the "docBase" property of a context can be
> > an absolute pathname.
> >
> > I use this feature for rapid development (coupled
> > with the custom Ant
> > tasks that talk to the Manager webapp, by installing
> > the output directory
> > of my build process. So, now my development cycle
> > is:
> > (1) ant compile
> > (2) ant install
> > (3) <<test things>>
> > (4) <<fix something>>
> > (5) ant compile reload
> > (6) goto (3) until its time for a beer
> > (7) ant remove
> >
> > and never have to shut down Tomcat for anything.
> > (The only time you
> > need to do a remove and install again is if you
> > change web.xml - reload
> > only pays attention to updated classes so that it
> > can run faster.)
> >
> > The "Application Developer's Guide" that comes with
> > 4.1.x explains this,
> > and includes a nice build.xml file to start with.
> > Besides supporting the
> > Ant tasks described above, it automatically sets up
> > your compile classpath
> > to reflect the environment that will be present at
> > runtime (for example,
> > it adds all the JAR files in common/lib and the
> > other shared directories).
> >
> > > After restarting Tomcat 4.1, the
> > > newly installed application is not visible. Am I
> > doing
> > > something wrong here? or is it a bug in 4.1?
> > >
> >
> > Saving the updated state (into server.xml) is a
> > feature that is currently
> > still being added -- I think you'll see that
> > finished by 4.1.5.
> >
> > > 2. How do you pass the war file to the 4.1 deploy
> > > command? The documentation says - "Upload the web
> > > application archive (WAR) file that is specified
> > as
> > > the request data in this HTTP PUT ". Umm.. how do
> > I do
> > > this via a browser?
> > >
> >
> > You don't -- it requires a client program. Simplest
> > way, again, is to use
> > the custom Ant <deploy> task which does all the
> > nitty gritty for you.
> > You can easily incorporate the execution of this
> > into a shell script.
> >
> > > On another train..what is the difference between
> > what
> > > the install and deploy commands do? AFAIK, both
> > seem
> > > to be installing and starting the app..
> > >
> >
> > Install connects an unpacked directory, or a WAR
> > file, directly to a
> > running Tomcat installation. Because nothing has to
> > be copied, this runs
> > pretty quickly, and is ideal for development.
> > However, the directory or
> > WAR file has to be on the same machine that Tomcat
> > is running on.
> >
> > Deploy lets you run a tool (or Ant script) on a
> > separate computer. It
> > takes longer because of the need to upload the WAR,
> > but you can run
> > it from anywhere, not just the same server. Over
> > time, I expect to see
> > management tools and IDEs incorporate support for
> > using the deploy and
> > undeploy features behind the scenes for you -- it
> > makes for very easy
> > Tomcat application management.
> >
> > > Thanks!!!
> > >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat 4.1/4.0 manager application
Posted by Sam Ewing <ja...@yahoo.com>.
Thanks for all the help Craig. A couple of other
doubts :-)
1. In Tomcat 4.1, when a install command is run, how
is the web application 'installed'. I mean, the
application is neither copied into webapps, nor a
Context entry added to server.xml; so how does the
requests for /new_app (if that is the context path)
sent to the new application? Is everything manipulated
in the in memory representation of server.xml?
2. In Tomcat 4.0, the remove command doesnt remove the
installed app from application base.. is that ok since
the remove in 4.0 is actually an undeploy?
3. In Tomcat 4.0, the install copies the web app into
the application base.. yet when I restart Tomcat, the
'manager list' doesnt show this new webapp, nor does
is this application accessible. Why is this when the
application has been unpacked into application base?
Sorry for all the questions!
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Fri, 14 Jun 2002, Sam Ewing wrote:
>
> > Date: Fri, 14 Jun 2002 13:00:25 -0700 (PDT)
> > From: Sam Ewing <ja...@yahoo.com>
> > Reply-To: Tomcat Users List
> <to...@jakarta.apache.org>
> > To: tomcat-user@jakarta.apache.org
> > Subject: Tomcat 4.1/4.0 manager application
> >
> > I'm facing a few problems with the Tomcat manager
> > application..
> >
> > 1. In 4.0.4, the install command copies the web
> app
> > into the appBase directory.. in 4.1.3, the install
> > does not do this; however the installed
> application is
> > availble for use.
>
> This is the correct behavior for the future -- it
> takes advantage of the
> fact that the "docBase" property of a context can be
> an absolute pathname.
>
> I use this feature for rapid development (coupled
> with the custom Ant
> tasks that talk to the Manager webapp, by installing
> the output directory
> of my build process. So, now my development cycle
> is:
> (1) ant compile
> (2) ant install
> (3) <<test things>>
> (4) <<fix something>>
> (5) ant compile reload
> (6) goto (3) until its time for a beer
> (7) ant remove
>
> and never have to shut down Tomcat for anything.
> (The only time you
> need to do a remove and install again is if you
> change web.xml - reload
> only pays attention to updated classes so that it
> can run faster.)
>
> The "Application Developer's Guide" that comes with
> 4.1.x explains this,
> and includes a nice build.xml file to start with.
> Besides supporting the
> Ant tasks described above, it automatically sets up
> your compile classpath
> to reflect the environment that will be present at
> runtime (for example,
> it adds all the JAR files in common/lib and the
> other shared directories).
>
> > After restarting Tomcat 4.1, the
> > newly installed application is not visible. Am I
> doing
> > something wrong here? or is it a bug in 4.1?
> >
>
> Saving the updated state (into server.xml) is a
> feature that is currently
> still being added -- I think you'll see that
> finished by 4.1.5.
>
> > 2. How do you pass the war file to the 4.1 deploy
> > command? The documentation says - "Upload the web
> > application archive (WAR) file that is specified
> as
> > the request data in this HTTP PUT ". Umm.. how do
> I do
> > this via a browser?
> >
>
> You don't -- it requires a client program. Simplest
> way, again, is to use
> the custom Ant <deploy> task which does all the
> nitty gritty for you.
> You can easily incorporate the execution of this
> into a shell script.
>
> > On another train..what is the difference between
> what
> > the install and deploy commands do? AFAIK, both
> seem
> > to be installing and starting the app..
> >
>
> Install connects an unpacked directory, or a WAR
> file, directly to a
> running Tomcat installation. Because nothing has to
> be copied, this runs
> pretty quickly, and is ideal for development.
> However, the directory or
> WAR file has to be on the same machine that Tomcat
> is running on.
>
> Deploy lets you run a tool (or Ant script) on a
> separate computer. It
> takes longer because of the need to upload the WAR,
> but you can run
> it from anywhere, not just the same server. Over
> time, I expect to see
> management tools and IDEs incorporate support for
> using the deploy and
> undeploy features behind the scenes for you -- it
> makes for very easy
> Tomcat application management.
>
> > Thanks!!!
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat 4.1/4.0 manager application
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 14 Jun 2002, Sam Ewing wrote:
> Date: Fri, 14 Jun 2002 13:00:25 -0700 (PDT)
> From: Sam Ewing <ja...@yahoo.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Tomcat 4.1/4.0 manager application
>
> I'm facing a few problems with the Tomcat manager
> application..
>
> 1. In 4.0.4, the install command copies the web app
> into the appBase directory.. in 4.1.3, the install
> does not do this; however the installed application is
> availble for use.
This is the correct behavior for the future -- it takes advantage of the
fact that the "docBase" property of a context can be an absolute pathname.
I use this feature for rapid development (coupled with the custom Ant
tasks that talk to the Manager webapp, by installing the output directory
of my build process. So, now my development cycle is:
(1) ant compile
(2) ant install
(3) <<test things>>
(4) <<fix something>>
(5) ant compile reload
(6) goto (3) until its time for a beer
(7) ant remove
and never have to shut down Tomcat for anything. (The only time you
need to do a remove and install again is if you change web.xml - reload
only pays attention to updated classes so that it can run faster.)
The "Application Developer's Guide" that comes with 4.1.x explains this,
and includes a nice build.xml file to start with. Besides supporting the
Ant tasks described above, it automatically sets up your compile classpath
to reflect the environment that will be present at runtime (for example,
it adds all the JAR files in common/lib and the other shared directories).
> After restarting Tomcat 4.1, the
> newly installed application is not visible. Am I doing
> something wrong here? or is it a bug in 4.1?
>
Saving the updated state (into server.xml) is a feature that is currently
still being added -- I think you'll see that finished by 4.1.5.
> 2. How do you pass the war file to the 4.1 deploy
> command? The documentation says - "Upload the web
> application archive (WAR) file that is specified as
> the request data in this HTTP PUT ". Umm.. how do I do
> this via a browser?
>
You don't -- it requires a client program. Simplest way, again, is to use
the custom Ant <deploy> task which does all the nitty gritty for you.
You can easily incorporate the execution of this into a shell script.
> On another train..what is the difference between what
> the install and deploy commands do? AFAIK, both seem
> to be installing and starting the app..
>
Install connects an unpacked directory, or a WAR file, directly to a
running Tomcat installation. Because nothing has to be copied, this runs
pretty quickly, and is ideal for development. However, the directory or
WAR file has to be on the same machine that Tomcat is running on.
Deploy lets you run a tool (or Ant script) on a separate computer. It
takes longer because of the need to upload the WAR, but you can run
it from anywhere, not just the same server. Over time, I expect to see
management tools and IDEs incorporate support for using the deploy and
undeploy features behind the scenes for you -- it makes for very easy
Tomcat application management.
> Thanks!!!
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>