deployment / war unpacking and Context definition?

2007-04-26 Thread Kristian Rink
-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: [EMAIL PROTECTED] * 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?

2007-04-26 Thread Caldarale, Charles R
 From: Kristian Rink [mailto:[EMAIL PROTECTED] 
 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: deployment / war unpacking and Context definition?

2007-04-26 Thread Kristian Rink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Chuck;

first off, thanks for the reply.

[Caldarale, Charles R [EMAIL PROTECTED] @ 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: [EMAIL PROTECTED] * 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?

2007-04-26 Thread Caldarale, Charles R
 From: Kristian Rink [mailto:[EMAIL PROTECTED] 
 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: deployment / war unpacking and Context definition?

2007-04-26 Thread Kristian Rink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Chuck;

[Caldarale, Charles R [EMAIL PROTECTED] @ 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: [EMAIL PROTECTED] * 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-