You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kristian Rink <kr...@zimmer428.net> on 2007/04/26 13:42:58 UTC
deployment / war unpacking and Context definition?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folks,
feeling kinda ashamed asking such a (probably rather basic) question,
but nevertheless: By now, I only built applications packed to *.war
files and then thrown to a tomcat /webapps/ folder, which obviously
made / makes tomcat redeploy the application - so far, so good.
However, in order to get a JDBC resource set up and running, I added a
context definition like this ...
<Context path="/jdbclink" reloadable="true">
...
<Resource name="jdbc/SQLDB" auth="Container" ... />
...
</Context>
... and then dumped in a jdbclink.war file. Deployment works fine the
very first time, and then never again. :o Even worse, removing the
webapps/jdbclink/ folder while the container is running doesn't make
tomcat unpack / redeploy the .war file. Likewise, even placing a new
war file in webapps and restarting the container doesn't do - I have to
stop tomcat and manually remove the unpacked web application in webapps
to get the war redeployed again. Haven't messed with any other
settings so far, the Host declaration looks like this...
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
We're talking tomcat 5.5.20 atop Ubuntu/JDK 1.6 here. Can anyone
enlighten me why in this configuration tomcat doesn't redeploy the
application when having a new war file dropped to webapps (by removing
the Context definition from server.xml, this does work again...)? It's
not all _that_ bad the way it is now, but having to shut down tomcat
and manually remove the webapp to get it redeployed is not that fine on
a production system running more than just that very application. :)
Thanks in advance and bye,
Kristian
- --
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
"One dreaming alone, it will be only a dream; many dreaming together
is the beginning of a new reality." (Hundertwasser)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGMJBJcxBAPOA1m6wRAsJjAJ9HigISz9g/4YdZ1Mv2rw+7EBt21wCbBGp+
myjQt53ccWBHayGdXzCiG5U=
=fKcF
-----END PGP SIGNATURE-----
Re: deployment / war unpacking and Context definition?
Posted by Kristian Rink <kr...@zimmer428.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck;
["Caldarale, Charles R" <Ch...@unisys.com> @ Thu, 26 Apr 2007
09:56:45 -0500]
> changes are required, which is why it's strongly discouraged these
> days. The <Context> element should be defined in META-INF/context.xml
> within the webapp structure; alternatively, it can be placed in
Thanks for pointing this out - this seems to have solved it, by now
the .war both deploys again and the datasource is there for the context
to use. Good to know getting it done this way is better (indeed messing
with server.xml and restarting the container afterwards is a bad thing
most of the time).
Thanks for your help and bye,
Kristian
- --
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
"One dreaming alone, it will be only a dream; many dreaming together
is the beginning of a new reality." (Hundertwasser)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGMMBWcxBAPOA1m6wRAiLHAJ93e0TfUCHC0LqTkDHjh94lH2IoYwCeLsIf
aRhUOdZppg5nrdlIjJ61kCo=
=6vlB
-----END PGP SIGNATURE-----
RE: deployment / war unpacking and Context definition?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Kristian Rink [mailto:kristian@zimmer428.net]
> Subject: Re: deployment / war unpacking and Context definition?
>
> It lives inside the Host definition in server.xml, according to the
> example pointed out in
>
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.h
tml
Unfortunately, several of the examples in the doc have not kept up with
recommended practice for current versions of Tomcat. Placing the
<Context> element in server.xml requires restarting Tomcat if any
changes are required, which is why it's strongly discouraged these days.
The <Context> element should be defined in META-INF/context.xml within
the webapp structure; alternatively, it can be placed in
conf/Catalina/[host]/[appName].xml if desired; the latter location will
override the one in META-INF if both are present. The URI path is
automatically determined by the name of the app's .war file. Look here
for details:
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
I wouldn't expect the presence of the <Context> element in server.xml to
prevent redeployment, but you never can tell...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: deployment / war unpacking and Context definition?
Posted by Kristian Rink <kr...@zimmer428.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck;
first off, thanks for the reply.
["Caldarale, Charles R" <Ch...@unisys.com> @ Thu, 26 Apr 2007
09:36:38 -0500]
> > <Context path="/jdbclink" reloadable="true">
> Where is the above <Context> declaration? If it's anywhere other than
> in server.xml (where it shouldn't be), the path attribute must not be
> present.
It lives inside the Host definition in server.xml, according to the
example pointed out in
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
- - I already played around with adding and removing attributes like
"path" and "docPath" without any obvious change for the better. Is
there a "better" way to set this up?
>
> > removing the webapps/jdbclink/ folder while the container is
> > running doesn't make tomcat unpack / redeploy the .war file.
>
> Deleting arbitrary files out from under a running process is just
> asking for trouble. What happens if you redeploy using an appropriate
> mechanism, such as Tomcat's manager app or Ant scripts?
I will have a look at the manager application then. By now I "just"
deployed using the export-to-war facility of eclipse and relying upon
tomcat to deploy the application as soon as the new war is there... ;)
Anyhow, thanks and best regards,
Kristian
- --
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
"One dreaming alone, it will be only a dream; many dreaming together
is the beginning of a new reality." (Hundertwasser)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGMLtccxBAPOA1m6wRAqZfAJ9twgr0thlgQRjsYtTour5o+I5ceACfcP71
mm+OTHAkncA/587mUJBlufw=
=O2Ld
-----END PGP SIGNATURE-----
RE: deployment / war unpacking and Context definition?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Kristian Rink [mailto:kristian@zimmer428.net]
> Subject: deployment / war unpacking and Context definition?
>
> <Context path="/jdbclink" reloadable="true">
> ...
> <Resource name="jdbc/SQLDB" auth="Container" ... />
> ...
> </Context>
Where is the above <Context> declaration? If it's anywhere other than
in server.xml (where it shouldn't be), the path attribute must not be
present.
> removing the webapps/jdbclink/ folder while the container is
> running doesn't make tomcat unpack / redeploy the .war file.
Deleting arbitrary files out from under a running process is just asking
for trouble. What happens if you redeploy using an appropriate
mechanism, such as Tomcat's manager app or Ant scripts?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org