Re: Remote deployment in tomcat

2007-12-27 Thread Marcio Camurati
Hi,

Maybe CruiseControl can help you to make it, it's a project that for create 
continuous build process scheduled:

http://cruisecontrol.sourceforge.net/

See ya.
Marcio Camurati

 Thu, 27 Dec 2007 00:57:42 -0500, Louis [EMAIL PROTECTED] escreveu:

 Shreekanta Prasad wrote:
   
  Hi All,
 
  I want to deploy my web application(in the form of a war file)
  remotely through ant script.
  I have written ant script for that and it is doing deployment
  properly to the remote host.
  But still I am getting old application itself new changes are not
  getting updated.
  Once we restart the apache it will work.The reason for this work
  floder of tomcat.
  After restarting the new changes are getting updated to the work
  folder.

  Is there any way to trigger the tomcat to delete work folder
  automatically and create by itself 
  without restart if the .war file modified ?
 
  Or Is there any trigger event associated with tomcat so that we can
  configure so as restarting of tomcat
  occurs if we modify the war file ?
 
  Hot deployment feature is there in tomacat.
 
I am using Tomacat 5.5 not command line startup using as a windows
  service(system try icon)
Operating system is windows 2003 server.
Ant version is 1.7.0 .
 
 
 
  Thanks and Regards -
  Shreekanta Prasad
  Bangalore,Karnataka
  India.

 I work this way with JBoss all the time. In the ant script you can 
 simply code in the call to delete the appropriate work directory.  See 
 the ant delete task.
 http://ant.apache.org/manual/CoreTasks/delete.html
 
 My guess as to the actual problem:
 Since you're copying a file across the network it can take a little 
 while for the transfer to complete. I don't know about Tomcat but in 
 JBoss the container can see the new file and try to unzip it before it's 
 fully copied over. The copy still works but the unzip attempt fails 
 (since the copy isn't done yet) and the hot deploy gets cancelled. The 
 work-around to this is to copy the file to a temp folder other than the 
 deploy directory (where tomcat/jboss expects to find the war). This 
 allows the copy to complete without Tomcat attempting to unzip a partial 
 file. After the copy task you then use a move to move the file from 
 the temp folder to the deploy folder _on the same server/drive_. Since 
 the move simply updates the file pointer tomcat will only see the file 
 once the operation is complete. This guarantees that tomcat can acutally 
 unzip the file.
 
 It's quite possible that this is the problem you're having and the empty 
 work directoy isn't a part of it.
 
 I hope that helps. Best Regards,
 
 Louis
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Problem with Mod_JK 1.2.15 and 1.2.18

2006-09-01 Thread Marcio Camurati
Hi everyone, 

We have a application that run at the Tomcat container. This application was 
made at the Tomcat 4.1 using the Mod_jk 1.2.12 with this configuration the 
application run perfectly without any problem, at this days we want to make an 
upgrade at the servers to use the new Mod_Jk 1.2.15 or 1.2.18, but when we do 
this the application broken. The problem is that with this new Mod_jk the 
Exceptions was never call for example at this code:

[code]
try
{
 while (true)
 {
  out.println(Nonononononnoonnonono);

  try
  {
   Thread.Sleep(1000);
  } catch(Exception ex) {}
 }
} catch(Exception ex) {
 try {
  BufferedWriter writer = new BufferedWriter(new 
FileWriter(/srv/www/default/html/log/exception.txt));
  writer.write(Eror !);
  writer.close();
  writer = null;
 } catch (IOException ioe) {
  ioe.printStackTrace();
 }
}
[/code]

When the brownser is closed the server never create the file (exception.txt) it 
will only create this file when the Tomcat is shuted down, with the older 
version 1.2.12 or oldest the server always call this exception beforer 1 or 2 
seconds and create the file.

We open at the Bugzila a report of this problem 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=39290) but didn't have any 
help to fix it.

Thanx.

Marcio Camurati

-
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: Problem with Mod_JK 1.2.15 and 1.2.18

2006-09-01 Thread Marcio Camurati
Hi,

Fred I forget to say at the post that I use it (JkOptions +FlushPackets) at my 
httpd.conf and it fix the flush call, but don't get a exception only when I 
shutdown the container. I found this post of another person about the same 
problem (http://threebit.net/mail-archive/tomcat-users/msg00254.html) but 
without answer.

Thanx

Marcio Camurati

On Fri, 1 Sep 2006 10:45:45 -0700 (PDT), fredk2 [EMAIL PROTECTED] escreveu:

 De: fredk2 [EMAIL PROTECTED]
 Data: Fri, 1 Sep 2006 10:45:45 -0700 (PDT)
 Para: users@tomcat.apache.org
 Assunto: Re: Problem with Mod_JK 1.2.15 and 1.2.18
 
 
 i think you need this in your httpd.conf mod_jk related configuration
 section:
 
 JkOptions +FlushPackets
 
 Rgds, Fred
 
 
 Marcio Camurati wrote:
  
  Hi everyone, 
  
  We have a application that run at the Tomcat container. This application
  was made at the Tomcat 4.1 using the Mod_jk 1.2.12 with this configuration
  the application run perfectly without any problem, at this days we want to
  make an upgrade at the servers to use the new Mod_Jk 1.2.15 or 1.2.18, but
  when we do this the application broken. The problem is that with this new
  Mod_jk the Exceptions was never call for example at this code:
  
  [code]
  try
  {
   while (true)
   {
out.println(Nonononononnoonnonono);
  
try
{
 Thread.Sleep(1000);
} catch(Exception ex) {}
   }
  } catch(Exception ex) {
   try {
BufferedWriter writer = new BufferedWriter(new
  FileWriter(/srv/www/default/html/log/exception.txt));
writer.write(Eror !);
writer.close();
writer = null;
   } catch (IOException ioe) {
ioe.printStackTrace();
   }
  }
  [/code]
  
  When the brownser is closed the server never create the file
  (exception.txt) it will only create this file when the Tomcat is shuted
  down, with the older version 1.2.12 or oldest the server always call this
  exception beforer 1 or 2 seconds and create the file.
  
  We open at the Bugzila a report of this problem
  (http://issues.apache.org/bugzilla/show_bug.cgi?id=39290) but didn't have
  any help to fix it.
  
  Thanx.
  
  Marcio Camurati
  
  -
  To start a new topic, e-mail: users@tomcat.apache.org
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
 -- 
 View this message in context: 
 http://www.nabble.com/Problem-with-Mod_JK-1.2.15-and-1.2.18-tf2202971.html#a6103299
 Sent from the Tomcat - User forum at Nabble.com.
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Doubt About the Flush() at Tomcat 5.5

2006-04-06 Thread Marcio Camurati
Hi everyone !

At the project we use the Tomcat 5.0 and implement it under this version, 
yesterday we make a atualization of the container using the Tomcat 5.5.14, but 
I found a problem with the buffer, at the 5.0 when call the method flush() ou 
flushbuffer() the container send to the client screen everithing and clean the 
buffer, but now at this new version they only send it when the buffer has a 
minimum size and not when I call it to flush the buffer, anyone see this 
problem and know how can I fix it at the application, because at the 5.0 it 
work wonderful. I send the code that I use at the tests.

[code]
...
String texto = !-- ACERTANDO BUFFER DO NAVEGADOR IE --\n;

PrintWriter out = response.getWriter();
out.println(response.getBufferSize());

while (true)
{
out.println(texto);
out.flush(); 
response.flushBuffer();

try {
Thread.sleep(1000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
...
[/code]

Thanks,

Marcio Camurati