Damian Krzeminski wrote:
Laurentiu Ceausescu wrote:
Hi all,
Regarding XX-5805 - Software Updates - No option to restart or reboot
after updating the software,
I made an update, without Software Updates page from UI, following next
scenario:
- sipXecs is running and I don't have any browser instance running;
- I used the following command for update: yum update -y --disablerepo=*
--enablerepo=sipxecs*
After update was completed (from revision 4.0.1-015734 to 4.0.1-015788),
I checked sipxconfig.log and I didn't see any errors.
But when I opened the browser with the sipXecs app I saw the next errors:
HTTP ERROR: 500
Unable to construct service sipxconfig.DiscardSessionFilter: Error
building service sipxconfig.DiscardSessionFilter: Unable to convert type
'site.DiscardSessionFilter' to a Java class, either as is, or in package
org.sipfoundry.sipxconfig.
RequestURI=/sipxconfig/app
and in sipxconfig.log:
"2009-06-23T07:23:06.612000Z":4:JAVA:WARNING:moon.itcnetworks.ro:P1-19:00000000:sipXconfig-web:"sipXconfig-web:
ServletException"
javax.servlet.ServletException: Unable to construct service
sipxconfig.DiscardSessionFilter: Error building service
sipxconfig.DiscardSessionFilter: Unable to convert type
'site.DiscardSessionFilter' to a Java class, either as is, or in package
org.sipfoundry.sipxconfig.
at
org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:65)
...
I think that this isn't a sipxconfig error. What do you think?
Anyway, after sipX is restarted, everything works fine.
I attached sipxconfig.log and sipxsupervisor.log on Jira.
http://track.sipfoundry.org/secure/attachment/20036/sipxconfig.log
http://track.sipfoundry.org/secure/attachment/20037/sipxsupervisor.log
Regards,
Laurentiu
Well - DiscardSessionFilter (and the way we use it) is definitely
sipXconfig. Installing a new version of sipxconfig RPM replaces the
'sipxconfig.war'. And it looks like sipXconfig/tapestry/jetty (one of
those) does not like it.
We can either try to find out why (and fix it) or we can make sure that
sipXconfig gets automatically restarted after the upgrade. That would mean
changing the UI and potentially changing the back-end implementation of an
update for the primary server.
Other ideas?
D
I think that original code was made with restart sipX after the updates
was installed, without any UI option.
I believe that sipx-swadmin.py was responsible with the sipX restart
after upgrade is finished.
But for unknown reason that didn't happen. This is why XX-5805 was open.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
