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:0
0000000: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.servi
ce(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
_______________________________________________
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/
