Details
-
Type: Bug
-
Status: Closed
-
Priority: 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.
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
- duplicates
-
ICE-3659 Deadlock on application exception and re-deploy
- Closed
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.