ICEfaces
  1. ICEfaces
  2. ICE-3764

Can not republish application after error

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.2
    • Fix Version/s: 1.7.2-SP2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP, WebSphere Application Server 6.0 (meaning Java 1.4), RAD 7.0.0.7, Spring Web Flow 2.0.3

      Description

      We are using ICEfaces 1.7.2 together with Spring Web Flow.

      If we just add our EAR file to the WAS server, all is well, furthermore we can make changes to our application and then just republish it. But....if we introduce some sort of error, say referencing a bean that does not exist, like so:

      <ice:outputText value="#{boom.bang}" />

      where boom is a Spring Bean defined like so:

      <bean id="boom" class="im.so.not.here" />

      (in case you couldn't tell...no, there is no class named im.so.not.here :-)

      our application fails.....of course. If we correct the error and wish to republish our application, we can not do so. RAD just hangs with "Publishing to WebSphere Application Server 6.0" stuck on 100%.

      If we cancel our publishing attempt and try to stop the server, it appears to be stopped alright, but when looking at the process manager in Windows we can see that it is not. The only thing to do (as far as we can see) is to terminate the WAS server process in the process manager.

      The only line in the console that seems to hint anything is this:

      [11-11-08 09:03:11:662 CET] 00000048 MainSessionBo W com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet$2 run [1] views have accumulated updates

      Which is shown when trying to publish both with and without errors. When publishing with errors, this is the last line shown.

      To me it seems like something is not terminated properly when an error occurs (this is just wild guessing).

      And one final observation. We did not have this problem when using ICEfaces 1.7.1

      I admit, it's not much to go from, but if you have any further questions or comments, do not hesitate to contact me.

        Issue Links

          Activity

          Peter Bødskov created issue -
          Hide
          Flemming Joensson added a comment -

          I can confirm this problem. I use WAS 6.0.2.9, WPS 6.0.1.4 and RAD 7.0.0.7, Icefaces 1.7.2 (no spring in my system)

          When this log entry appears (MainSessionBo W com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet$2 run [1] views have accumulated updates) it is no longer possible to publish to the server - it is not a RAD problem, as it also blocks publishing from command line.

          Also it is impossible to shut down the server - the only way to get rid of the problem is to kill the java process running the server.

          Show
          Flemming Joensson added a comment - I can confirm this problem. I use WAS 6.0.2.9, WPS 6.0.1.4 and RAD 7.0.0.7, Icefaces 1.7.2 (no spring in my system) When this log entry appears (MainSessionBo W com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet$2 run [1] views have accumulated updates) it is no longer possible to publish to the server - it is not a RAD problem, as it also blocks publishing from command line. Also it is impossible to shut down the server - the only way to get rid of the problem is to kill the java process running the server.
          Hide
          Herbert Dowalil added a comment -

          i got the same problem on my WAS 6.0 - is there a solution or at least a workaround for it?

          Show
          Herbert Dowalil added a comment - i got the same problem on my WAS 6.0 - is there a solution or at least a workaround for it?
          Hide
          Peter Bødskov added a comment -

          Problem seems to have disappeared when upgrading to SP1.

          Hope this also applies to you Flemming and Herbert

          Show
          Peter Bødskov added a comment - Problem seems to have disappeared when upgrading to SP1. Hope this also applies to you Flemming and Herbert
          Peter Bødskov made changes -
          Field Original Value New Value
          Link This issue duplicates ICE-3659 [ ICE-3659 ]
          Ken Fyten made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 1.7.2-SP2 [ 10162 ]
          Resolution Fixed [ 1 ]
          Hide
          Greg Dick added a comment -

          Trying to check the status of this bug under 1.8.2 and I'm wondering if I can get some clarity on "republish". I know it sounds like splitting hairs, but I don't seem to be able to see changes made to a health application without stopping the old application, re-installing the new app, and restarting the app. Is this the procedure that you are going through when you see this issue?

          On the Websphere Administration Console there is start, stop, install, uninstall, update, roll update, and a few more that don't apply. The only applicable button I see might be update, but that certainly doesn't make application changes appear without stopping and restarting the app.

          I think the technical reasons for this issue have been resolved in at least 1.8.1. It would be helpful if someone who works with WebSphere on a regular basis could confirm this.

          Show
          Greg Dick added a comment - Trying to check the status of this bug under 1.8.2 and I'm wondering if I can get some clarity on "republish". I know it sounds like splitting hairs, but I don't seem to be able to see changes made to a health application without stopping the old application, re-installing the new app, and restarting the app. Is this the procedure that you are going through when you see this issue? On the Websphere Administration Console there is start, stop, install, uninstall, update, roll update, and a few more that don't apply. The only applicable button I see might be update, but that certainly doesn't make application changes appear without stopping and restarting the app. I think the technical reasons for this issue have been resolved in at least 1.8.1. It would be helpful if someone who works with WebSphere on a regular basis could confirm this.
          Hide
          Peter Bødskov added a comment -

          Hi Greg

          I'll try to clarify.

          We are using RAD together with our WebSphere servers, and this means that we can start and stop the servers from within RAD (just like you can with say Tomcat in Eclipse). Furthermore we can add new projects to the server, from within RAD. And when we change something in the project/application (eg. edit a bean or a facelet page), we are able to right click on the application in the servers tab of RAD and select 'republish'. Behind the scenes, what happens is probably that the application is stopped, reistalled and started, but for us it's just republish

          So, in other words, we do not use the WebSphere Administration Console for installing our apps (at least not when just developing on our local machines), this is all done in RAD.

          I have not seen this problem since switching from 1.7.2 to 1.7.2-sp1, so I think too that you've nailed it.

          Hope the above explanation helps you.

          Show
          Peter Bødskov added a comment - Hi Greg I'll try to clarify. We are using RAD together with our WebSphere servers, and this means that we can start and stop the servers from within RAD (just like you can with say Tomcat in Eclipse). Furthermore we can add new projects to the server, from within RAD. And when we change something in the project/application (eg. edit a bean or a facelet page), we are able to right click on the application in the servers tab of RAD and select 'republish'. Behind the scenes, what happens is probably that the application is stopped, reistalled and started, but for us it's just republish So, in other words, we do not use the WebSphere Administration Console for installing our apps (at least not when just developing on our local machines), this is all done in RAD. I have not seen this problem since switching from 1.7.2 to 1.7.2-sp1, so I think too that you've nailed it. Hope the above explanation helps you.

            People

            • Assignee:
              Unassigned
              Reporter:
              Peter Bødskov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: