Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Message-ID: <111058835.1129076286509.JavaMail.jira@ajax.apache.org>
Date: Wed, 12 Oct 2005 02:18:06 +0200 (CEST)
From: "Rich Feit (JIRA)" <dev@beehive.apache.org>
To: dev@beehive.apache.org
Subject: [jira] Resolved: (BEEHIVE-960) Reload war problem when following
 tutorial
In-Reply-To: <1422874229.1128349427783.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/BEEHIVE-960?page=all ]
     
Rich Feit resolved BEEHIVE-960:
-------------------------------

    Resolution: Won't Fix

I actually tracked this down to an issue with Commons Digester.  I entered it as http://issues.apache.org/bugzilla/show_bug.cgi?id=37034 .  I also provided a patch to fix it, so hopefully they'll make the change at some point.  The main issue as far as I'm concerned is that Tomcat changed its default behavior to prevent file locking under Windows.  See http://jakarta.apache.org/tomcat/faq/windows.html#lock for information and also for workarounds.

"Won't Fix" is a silly resolution status -- should be "Can't Fix"  :)

> Reload war problem when following tutorial
> ------------------------------------------
>
>          Key: BEEHIVE-960
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-960
>      Project: Beehive
>         Type: Bug
>   Components: Tutorials
>     Versions: V1Beta
>  Environment: Not Applicable
>     Reporter: Thomas Preston
>     Priority: Minor

>
> In the final step of create controls tutorial having done all other steps successfully, have a problem with redeployment of the war:
> http://beehive.apache.org/docs/1.0m1/controls/tutorial_controls.html#test_3
> Looks like redeploy needs to undeploy and then you have some object of type shared.SharedFlow in the session. When the redeploy occurs the shared.SharedFlow class can't be found at the time that it needs to reload the session.  This is no big deal as you can stop and start the server to see the new code working, but it makes the demo not very nice.  Here is the stack:
> Oct 3, 2005 4:10:09 PM org.apache.catalina.startup.HostConfig checkResources
> INFO: Undeploying context [/control_tutorial]
> Oct 3, 2005 4:10:10 PM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deploying web application archive control_tutorial.war
> Oct 3, 2005 4:10:10 PM org.apache.catalina.startup.ContextConfig applicationWebC
> onfig
> INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].
> StandardHost[localhost].StandardContext[/control_tutorial]
> Oct 3, 2005 4:10:10 PM org.apache.catalina.session.StandardManager doLoad
> SEVERE: ClassNotFoundException while loading persisted sessions: java.lang.Class
> NotFoundException: shared.SharedFlow
> java.lang.ClassNotFoundException: shared.SharedFlow
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
> der.java:1332)
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
> der.java:1181)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:242)
>         at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomO
> bjectInputStream.java:73)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:153
> 8)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 693)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at org.apache.catalina.session.StandardSession.readObject(StandardSessio
> n.java:1371)
>         at org.apache.catalina.session.StandardSession.readObjectData(StandardSe
> ssion.java:903)
>         at org.apache.catalina.session.StandardManager.doLoad(StandardManager.ja
> va:393)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira