Closed Bug 371656 Opened 14 years ago Closed 11 years ago

Cannot save a new calendar entry on an Openxchange server


(Calendar :: Provider: ICS/WebDAV, defect)

Sunbird 0.3.1
Windows XP
Not set


(Not tracked)



(Reporter: rm, Unassigned)



(2 files)

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.6 (like Gecko)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20070213 Sunbird/0.3.1

I connected Sunbird (Windows version) to an Openexchange server. 
The contents of my OX calendar is displayed without errors in Sunbird. However, when I try to insert a new appointment with Sunbird an error message appears after some time in a popup:

There has been an error reading data for calendar: oxs2. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'.

error number: 0x0
Publishing the calendar file failed
Status code: 500: Internal Server Error

I should mentiion that I have KDE Kontact with Korganizer running on a Linux system, too. No problem with these programs to connect to the webdav calendar module of the Openexchange server and no problem with creating appointments and inviting other people working on the OX system. So the Webdav and the access rights on the Openexchange system seem to be OK. 

The error described above appears with Sunbird on a Windows XP system.  

Reproducible: Always

Steps to Reproduce:
1. Connect to the .../servlet/webdav.ical of an Openexchange server
2. Insert a new appointment with Sunbird into the webdav calendar
3. wait some seconds for the error message
Version: unspecified → Sunbird 0.3.1
The 500 error is a servlet exception on the server side.  If you can get the stack trace from the server logs, that would likely help track this down.

If the change you're making with Sb/Ln occurs _before_ the 500, then attaching a copy of the resulting .ICS would be helpful.

One other thing:
Try to replicate this using one of the nightly builds.
Attached file tomcat log file
Attached file Catalina.out
I provided excerpts of the log files of the tomcat server and the corresponding catalina.out file. The exceptions occured when I tried to enter a new appointment via sunbird.

I am not a Java developer, so my options and possibilities for providing information are limited. I hope the exceptions help to track down the error. Please give precise instructions what to do next if you need more information.   

Kind regards
Setting QAWanted, since we finally have some logs from an Open Exchange server.  Could this be related to the other errors we have seen from OEX?
Keywords: qawanted
Ralph, Thank you very much for attaching the logs.  We'll look into them and let you know what we find.  In the meantime, would you be willing to see if you can reproduce (and get logs) for two other OpenExchange related defects?  We've had a hard time getting the reporters of those bugs to get us logs and we have not had the bandwidth on the team to set up and configure a test OpenExchange server.

We'd like you to check out bug 369076 and bug 339760, if possible.

Thanks for the help
Oops sorry, typo: should have been "and bug 339960"
I could solve my problem in the meantime. However, I still do not understand in detail what the cause of the problem really is. But at least I got an idea where to look at ...

I should mention that part of the contents of my present OX5 folders had their origin in a previous SLOX 4.1 system. My present OX5 server is based on a data migration from SLOX to an OX installation on a SLES 9 server. However, I have changed the configuration of LDAP, Samba, Postfix, Cyrus, ... a lot since the original installation. 

Today I tested Sunbird again - but with some "fresh" new OX folders that I generated in addition to the ones already present. I got the folder IDs (1642 for the calendar folder and 1650 for the task folder) from the OX WEB client interface. The webdav adress I now call from Sunbird reads 
(I got this way of referring to special folders from the OX forums).

Sunbird worked at once with these folders. At least I could enter appointments and tasks which were saved on the server. (However I get a time difference of one hour - so I see something similar as described in bug 339960).

I then tried my original calendar folder alone  (http://oxs2/servlet/webdav.ical?calendarfolder=25) with Sunbird. It also worked. So the problem resided somewhere in the task folder. I therefore started deleting old entries in my task folder. After some deletions everything worked. However, I could not detect anything special in the problematic task entries. 

In addition I tried to get Sunbird running with the OX folders of a colleague (the folders were also migrated from SLOX). Here the problem appears to be the other way round - the task folder is working, however the calendar folder causes error messages. 

Summary: Sunbird works well with freshly generated folders on my OX system. Old folders which in my case came from a SLOX migration cause problems - however I do not exactly know which entries or field contents are at the core of the trouble.  

I can live with such a situation because I can afford to generate additional folders. Nevertheless the problem should be investigated. And as I mentioned before: KDE's Kontact/Korganizer component can handle the folders that Sunbird obviously has problems with.   

And there is the additional problem of a one hour difference of the appointment entries: Whenever I enter an appointment for 16:00 it appears on the server side at 17:00. My Sunbird is running on a VMWARE XP Windows (within a Linux machine). The Win XP client is synchronized with the OX server. But I saw the problem on native Win XP machines, too.  

Could it be that you expect the server clock to be running with UTC (GMT)? In my situation I changed the server's local clock a while ago to local time. The reason was - as far as I remember - that this helped to get rid of a similar problem with KOrganizer. With Korganizer I once had experienced a two hour difference (1 hour deviation from GMT and one additional hour due to a wrong handling of summertime between client and server). But this was almost a year ago on a SUSE 10.1 machine. The bug was reported to the KOrganizer team at that time.            

Ralph Moenchmeyer
(In reply to comment #8)
> Hi, 
> I could solve my problem in the meantime. However, I still do not understand in
> detail what the cause of the problem really is. But at least I got an idea
> where to look at ...

Ralph, still occurs now?
> Ralph, still occurs now?

its a long time ago that I tried to use Sunbird. Actually I deinstalled bedcause of too many problems. I now have reinstalled the windows version just to have a brief look at its comaptibility with the present OX5 version (SP4 U1). 
Sorry, but it is worse than before - not only with Sunbird. 

Regarding KDEs Kontact/Kalendar a problem appeared in one of the 3.5.10 subversions which may lead to crashes. Maybe it is fixed already; I did not check. However, I found that the new Kontact/Kmail for KDE 4.1 works flawlessly and I have used it now for 2 weeks without any problems. Especially, there are no problems with the calendar interface.  

Now regarding Sunbird I had a look at version 0.9 for Windows. I opened a new calendar for the ICS source 
The folder was a freshly generated calender. I could see all my appointments at once. Even writing a new entry into the calender seemed to work - however the log for Tomcat shows an error: 

2008-10-31 13:30:37 StandardContext[/servlet]ical: GET
2008-10-31 13:30:37 StandardContext[/servlet]ical: PUT
2008-10-31 13:30:37 StandardContext[/servlet]ical: read ical content_type: text/calendar
2008-10-31 13:30:37 StandardContext[/servlet]ical: invalid versit object: VTIMEZONE
2008-10-31 13:30:37 StandardContext[/servlet]ical: STATUS: OK
2008-10-31 13:30:38 StandardContext[/servlet]ical: STATUS: OK
2008-10-31 13:30:38 StandardContext[/servlet]ical: STATUS: OK
2008-10-31 13:30:38 StandardContext[/servlet]ical: STATUS: OK

This error leads to dramatic effects afterwards - refreshing the calendar leads to a display of zero dates or appointments. Furthermore it is not possible to enter any new dates afterwards.

Regarding old calendars of my users the situation is even worse: 
An error appears during the writing operation on Sunbirds side:        

"Beim Schreiben in den Kalender fsg ist ein Fehler aufgetreten!

The Tomcat log says: 

2008-10-31 13:35:33 StandardContext[/servlet]ical: GET
2008-10-31 13:35:35 StandardContext[/servlet]ical: PUT
2008-10-31 13:35:35 StandardContext[/servlet]ical: read ical content_type: text/calendar
2008-10-31 13:35:35 StandardContext[/servlet]ical: invalid versit object: VTIMEZONE
2008-10-31 13:35:35 StandardContext[/servlet]ical: ERROR: ical.doPut: Errot at line 34, column 20: UTC time expected
2008-10-31 13:35:35 StandardContext[/servlet]ical: 500 msg --> Server Error

So much for now. 
Sorry - but as I said no problems for Kontact/Kalendar of KDE 4.2.1 and older 3.5.9 versions.  

Any more I can do to help? Excerpts from database tables ? Or other logs ?
This looks more like an openexchange bug. It seems its not accepting the VTIMEZONE object, which should be supported. Please retest with the latest versions of Lightning and Openexchange.
Closed: 11 years ago
Resolution: --- → INCOMPLETE
I agree that it is an OX bug. 

Unfortunately, for the time being I have no up to date OX 6 available - only OX 5 and the latter not with newest updates. 

Reason: License policy of OX. First they made me change to a small business version for 5 users. Than after changing to OX 6 I should again pay for an enterprise version for 25 users again to keep SLES as my server. No way!  
I regard more than stupid of OX that they do not to offer a commercial version for 5 users that runs on SLES or RHEL. 

I intend to use OX 6 - but the non commercial version - at some point in the future. I am sorry, but new tests have to wait until I find the time to experiment with OX 6 on SLES.
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.