Re: Problem on undeploy

2008-02-15 Thread Sébastien Piller

Hello,

I just tried it, and it worked :) I don't know if I can use this 
directive on my deployment server... I'll have a look with my hoster.


After some investigation, I'm now quite sure that it's a Wicket problem. 
I tried with a very simple project (Hello World) and it made the lock.


Could anybody tell me if it's a known bug or if I have to write a jira?

Thanks


TahitianGabriel a écrit :

Have you also tried the antiResourceLocking=true parameter?

That's the one I use and it works!

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problem on undeploy

2008-02-15 Thread Johan Compagner
i guess this is a problem of the jvm/jdk itself
I guess this is all related to the stupid i can't close a url connection
thing because i guess it has something to
do with the IInitializers lookup that somehowe holds on the something



On Fri, Feb 15, 2008 at 9:29 AM, Sébastien Piller [EMAIL PROTECTED]
wrote:

 Hello,

 I just tried it, and it worked :) I don't know if I can use this
 directive on my deployment server... I'll have a look with my hoster.

 After some investigation, I'm now quite sure that it's a Wicket problem.
 I tried with a very simple project (Hello World) and it made the lock.

 Could anybody tell me if it's a known bug or if I have to write a jira?

 Thanks


 TahitianGabriel a écrit :
  Have you also tried the antiResourceLocking=true parameter?
 
  That's the one I use and it works!
 
 

  -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




RE: Problem on undeploy

2008-02-15 Thread Wang, Yuesong
It's not a wicket issue. When Tomcat has to access resources in a jar file of a 
web app, it may lock it. Another attribute your can try is antiJARLocking, 
which is a little nicer than autiResourceLocking. You really only need to set 
these attribute if you do hot redeployment, e.g. in a development environment. 
In a production environment where you will stop the server before undeployment, 
it doesn't really matter.

Yuesong

-Original Message-
From: Sébastien Piller [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 15, 2008 3:29 AM
To: users@wicket.apache.org
Subject: Re: Problem on undeploy

Hello,

I just tried it, and it worked :) I don't know if I can use this directive on 
my deployment server... I'll have a look with my hoster.

After some investigation, I'm now quite sure that it's a Wicket problem. 
I tried with a very simple project (Hello World) and it made the lock.

Could anybody tell me if it's a known bug or if I have to write a jira?

Thanks


TahitianGabriel a écrit :
 Have you also tried the antiResourceLocking=true parameter?

 That's the one I use and it works!

   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problem on undeploy

2008-02-14 Thread Sébastien Piller




Here is a Thread dump from Tomcat (after I have undeployed my app). It
doesn't speak about PageSavingThread, but if anybody see something
wrong

[2008-02-14 12:43:17] [1334 prunsrv.c] [debug] Procrun
log initialized
  [2008-02-14 12:43:17] [info] Procrun (2.0.3.0) started
  [2008-02-14 12:43:17] [info] Debugging Service...
  [2008-02-14 12:43:17] [1158 prunsrv.c] [debug] Inside
ServiceMain...
  [2008-02-14 12:43:17] [info] Starting service...
  [2008-02-14 12:43:17] [385 javajni.c] [debug] Jvm Option[0]
-Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat 6.0
  [2008-02-14 12:43:17] [385 javajni.c] [debug] Jvm Option[1]
-Dcatalina.base=C:\Program Files\Apache Software Foundation\Tomcat 6.0
  [2008-02-14 12:43:17] [385 javajni.c] [debug] Jvm Option[2]
-Djava.endorsed.dirs=C:\Program Files\Apache Software Foundation\Tomcat
6.0\common\endorsed
  [2008-02-14 12:43:17] [385 javajni.c] [debug] Jvm Option[3]
-Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\Tomcat
6.0\temp
  [2008-02-14 12:43:18] [385 javajni.c] [debug] Jvm Option[4]
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
  [2008-02-14 12:43:18] [385 javajni.c] [debug] Jvm Option[5]
-Djava.util.logging.config.file=C:\Program Files\Apache Software
Foundation\Tomcat 6.0\conf\logging.properties
  [2008-02-14 12:43:18] [385 javajni.c] [debug] Jvm Option[6]
-Djava.class.path=C:\Program Files\Apache Software Foundation\Tomcat
6.0\bin\bootstrap.jar
  [2008-02-14 12:43:18] [385 javajni.c] [debug] Jvm Option[7]
vfprintf
  [2008-02-14 12:43:18] [471 javajni.c] [debug] argv[0] = start
  [2008-02-14 12:43:19] [1007 prunsrv.c] [debug] Java started
org/apache/catalina/startup/Bootstrap
  [2008-02-14 12:43:19] [info] Service started in 2312 ms.
  [2008-02-14 12:43:20] [1250 prunsrv.c] [debug] Waiting worker to
finish...
  [2008-02-14 12:45:34] [info] Console CTRL+BREAK event signaled
  [2008-02-14 12:45:34] [info] 2008-02-14 12:45:34
  [2008-02-14 12:45:34] [info] Full thread dump Java HotSpot(TM)
Client VM (1.6.0_03-b05 mixed mode, sharing):
  [2008-02-14 12:45:34] [info] 
  [2008-02-14 12:45:35] [info] "http-8080-3" 
  [2008-02-14 12:45:35] [info] daemon 
  [2008-02-14 12:45:35] [info] prio=6 tid=0x02fcdc00 
  [2008-02-14 12:45:35] [info] nid=0x115c 
  [2008-02-14 12:45:35] [info] in Object.wait() 
  [2008-02-14 12:45:35] [info] [0x0384f000..0x0384fc14]
  [2008-02-14 12:45:35] [info] java.lang.Thread.State: WAITING
(on object monitor)
  [2008-02-14 12:45:35] [info]  at java.lang.Object.wait(Native
Method)
  [2008-02-14 12:45:35] [info]  - waiting on 0x2312b2f0 
  [2008-02-14 12:45:36] [info] (a
org.apache.tomcat.util.net.JIoEndpoint$Worker)
  [2008-02-14 12:45:36] [info]  at
java.lang.Object.wait(Object.java:485)
  [2008-02-14 12:45:36] [info]  at
org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
  [2008-02-14 12:45:36] [info]  - locked 0x2312b2f0 
  [2008-02-14 12:45:36] [info] (a
org.apache.tomcat.util.net.JIoEndpoint$Worker)
  [2008-02-14 12:45:36] [info]  at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442)
  [2008-02-14 12:45:36] [info]  at java.lang.Thread.run(Unknown
Source)
  [2008-02-14 12:45:37] [info] 
  [2008-02-14 12:45:37] [info] "http-8080-2" 
  [2008-02-14 12:45:37] [info] daemon 
  [2008-02-14 12:45:37] [info] prio=6 tid=0x02fcd800 
  [2008-02-14 12:45:37] [info] nid=0x1630 
  [2008-02-14 12:45:37] [info] in Object.wait() 
  [2008-02-14 12:45:37] [info] [0x0380f000..0x0380fc94]
  [2008-02-14 12:45:37] [info] java.lang.Thread.State: WAITING
(on object monitor)
  [2008-02-14 12:45:37] [info]  at java.lang.Object.wait(Native
Method)
  [2008-02-14 12:45:37] [info]  - waiting on 0x2312b378 
  [2008-02-14 12:45:38] [info] (a
org.apache.tomcat.util.net.JIoEndpoint$Worker)
  [2008-02-14 12:45:38] [info]  at
java.lang.Object.wait(Object.java:485)
  [2008-02-14 12:45:38] [info]  at
org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
  [2008-02-14 12:45:38] [info]  - locked 0x2312b378 
  [2008-02-14 12:45:38] [info] (a
org.apache.tomcat.util.net.JIoEndpoint$Worker)
  [2008-02-14 12:45:38] [info]  at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442)
  [2008-02-14 12:45:38] [info]  at java.lang.Thread.run(Unknown
Source)
  [2008-02-14 12:45:38] [info] 
  [2008-02-14 12:45:38] [info]
"com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2" 
  [2008-02-14 12:45:39] [info] daemon 
  [2008-02-14 12:45:39] [info] prio=6 tid=0x02eab800 
  [2008-02-14 12:45:39] [info] nid=0x14c8 
  [2008-02-14 12:45:39] [info] in Object.wait() 
  [2008-02-14 12:45:39] [info] [0x0378f000..0x0378fa14]
  [2008-02-14 12:45:39] [info] java.lang.Thread.State:
TIMED_WAITING (on object monitor)
  [2008-02-14 12:45:39] [info]  at java.lang.Object.wait(Native
Method)
  [2008-02-14 12:45:39] [info]  - waiting on 0x230a9498 
  [2008-02-14 12:45:40] [info] (a
com.mchange.v2.async.ThreadPoolAsynchronousRunner)
  [2008-02-14 12:45:40] [info]  at

Re: Problem on undeploy

2008-02-14 Thread Sébastien Piller




Hello,

thank you for your answer. I wrote a */META-INF/context.xml* file with
that in it:
?xml version="1.0" encoding="UTF-8"?
  Context path="/servlet" reloadable="true"
docBase="${catalina.home}/webapps"
   parameter
   nameantiJARLocking/name
   valuetrue/value
   /parameter
  /Context

But the problem stills Have I done a syntax error?


C S a crit:

  Have you tried the antiLocking options (antiJARLocking and
antiResourceLocking)? 
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html  I haven't but
they seem to speak to your problem with the left over jars




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problem on undeploy

2008-02-14 Thread Sébastien Piller




Yes, I made a syntax error... but even with the syntax bellow, the
problem stills...

Context path="/servlet" reloadable="true" docBase="servlet"
antiJARLocking="true"
/Context

Sbastien Piller a crit:

  
But the problem stills Have I done a syntax error?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problem on undeploy

2008-02-14 Thread TahitianGabriel

Have you also tried the antiResourceLocking=true parameter?

That's the one I use and it works!



Pills wrote:
 
  
 
 
 Yes, I made a syntax error... but even with the syntax bellow, the
 problem stills... 
 
 lt;Context path=/servlet reloadable=true docBase=servlet
 antiJARLocking=truegt; 
 lt;/Contextgt; 
 
 

-- 
View this message in context: 
http://www.nabble.com/Problem-on-undeploy-tp15477946p15492542.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]