Raymond Dans 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-swadmin.py is not responsible for restarting sipX. It > provides an interface to do that but its up to sipXconfig to call it. > > Raymond >
Well - it look to me like sipx-swadmin.py will have to be responsible for at the minimum sipXconfig restart. D. _______________________________________________ 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/
