ahh checked it out

antiResourceLocking copies the complete webapp to the java.io.tmpdir and makes that the
docroot. So that you can copy jars over the original location just fine
And i guess that is the location they monitor.

antJarLocking does another trick:

  if (antiJARLocking) {
                ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
                try {
                    String repository = entry.codeBase.toString();
                    if ((repository.endsWith(".jar"))
                            && (!(name.endsWith(".class")))) {
                        // Copy binary content to the work directory if not present
                        File resourceFile = new File(loaderDir, name);
                        url = "">                    }
                } catch (Exception e) {
                    // Ignore
                }
            }

and on another place all resources inside a jar are just extracted to a dir.
So they don't really load it from inside a jar. But always from disc.

johan


On 3/7/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
interessting, can you test with only antiJARLocking ?

because it seems to me that we have that specific problem


johan


On 3/7/06, Joshua Lim <[EMAIL PROTECTED]> wrote:
typo  - antiResourceLocking="true"



On 3/7/06, Joshua Lim < [EMAIL PROTECTED]> wrote:
I was having this similiar problem, I have a few apps on my isp (kattare incidentally) and I needed to redeploy each one without shutting the whole damn (pardon me) thing down. using the tomcat manager wasn't helping as it did not remove the WEB-INF/lib directory and was causing

"SEVERE: ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException : wicket.Page$4
java.lang.ClassNotFoundException: wicket.Page$4" ...

java.net forum suggested turning off the session persistence - here but that didn't work and the WEB-INF/lib was not deleted by tomcat, only shutting it down was I able to remove it on the command line as it is probably locked.

another thread also on java.net mentioned something about setting anti-jar locking and anti-resource locking in the contect.xml for Tomcat which I thought might solve the problem

so now, when I package my war file I include the META-INF/context.xml which when I cp onto the webapp dir deploys nicely without complaining...

<Context
    path="/myApp"
    docBase="myApp"
    reloadable="true"
    unpackWAR="true"
    override="true"
    antiJARLocking="true"
    antiResourceLocaking="true">
    <Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false" />
</Context>

n.b . according to context.xml doc on apache there are side effects to on jsp - but heck, I'm using wicket !

Is this the right way to go? I am using wicket1.1 and tomcat 5.5

Josh









On 8/26/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
This isnt just a development-time problem. This also happens when you are
deploying a new version of your app, and if it's a hosted tomcat server you
are screwed.

-Igor





Reply via email to