facebook

Changed to Struts FormBeans causes Server Failure in debug

  1. MyEclipse IDE
  2.  > 
  3. Java EE Development (EJB, JSP, Struts, XDoclet, etc.)
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #261600 Reply

    We are on Weblogic 8.1 SP5 and Struts 1.1 classes.

    When we are running the server in Debug mode and modify the Struts ActionForm subclasses, the server fails and requires a restart. After which it works just fine. Sometimes it even gives the message that hot deployment failed and gives Terminate, restart, etc. options. So looks like the hot deployment fails in certain cases. Can we configure the server to restart everytime there is a change in certain specific type of classes ? Or something like that ?

    And also, any changes to the struts-config.xml file requires a redeployment. Is that normal ? We are deployed in exploded mode.

    Thanks

    #261666 Reply

    Riyad Kalla
    Member

    This is actually the expected behavior, there are two things happening here that cause this:

    1) The hot-sync spec of changed bytecode into a running VM is very limited. Sun has defined very specific situations when hot syncing code will work and that is when the shape of the class stays the same. Shape refers to class member variables and methods, these cannot change, but the contents of code bodies can change. So if you are adding/removing or editing method definitions or member variables, hot syncing will fail. Additionally, newer VM’s tend to handle hot syncing better than older VMs, so if you are on an early 1.4.2 or 1.4 release for example, hot syncing will fail often, where as an older 1.5.0 release may succeed more often.

    2) The Struts class (ActionServlet) that is coded to read the struts-config.xml file was not written to poll the file for changes and reload them when it see thems. So redeploying new struts-config.xml files will not trigger a reload unless you restart the application’s context. In Tomcat this is done via the Tomcat Manager, you can just flip over to the admin interface, and hit the reload button. I’m sure Weblogic has something similar from the admin interface.

    Also, there is a new change in MyEclipse 5.1 where after a redeploy, we no longer stop when we hit a locked file AND after the redeploy is done, we automatically touch the web.xml file, even if it hasn’t changed because about 1/2 of the app servers out there will recognize an updated timestamp on the web.xml file, and reload the webapp in response to it. So we thought we could make things easier for our developers with better/more robust defaults like that.

    #262068 Reply

    Riyad,

    Although what you are saying is correct on conceptual level, my issue was primarily due to two things :

    1) I was compiling my code with wrong version of JDK (1.5), and Weblogic was running on 1.4.2_08. So I changed my JRE settings, did a clean build and redeployed. That worked like magic on many issues.

    2) However, the struts issue was still not resolved. So I investigated the Weblogic forums and found that adding following property to Weblogic.xml would force the server to reload.
    <container-descriptor>
    <servlet-reload-check-secs>-1</servlet-reload-check-secs>
    </container-descriptor>

    As soon as I did that, everything started working as I was expecting. Feel free to share my solution with others if you want.

    Thanks for all your help though.

    #262071 Reply

    Riyad Kalla
    Member

    1) I was compiling my code with wrong version of JDK (1.5), and Weblogic was running on 1.4.2_08. So I changed my JRE settings, did a clean build and redeployed. That worked like magic on many issues.

    Very cool, glad that got resolved.

    2) These are actually not the same things (which makes it even more confusing). Hot-sync inside of a running virtual machine is immediate and is regulated by very strict rules. What you are doing is telling your app server to completely drop and reload the servlet when it changes (on Tomcat and some other app servers, there is even the concept of reloading the entire web app when a file changes). When you combine these 3 or 4 levels of synchronization and only as a last resort restart the app server itself, you really have a great development setup as you only ever need to restart the app server when it crashes or deploy a ton of major changes.

    Either way, great followup for other users in the similar position, thanks for sending that along.

Viewing 4 posts - 1 through 4 (of 4 total)
Reply To: Changed to Struts FormBeans causes Server Failure in debug

You must be logged in to post in the forum log in