Re: Are there problems with test.sharedrecords.org

[Andreas Kollegger]

After some investigation, I'm a little confused as to whether this ever
worked. It appears that the GCJ library for java.text.DateFormat is
simply broken. I've found older references to problems with GCJ parsing
dates, which reinforces the possibility. Also, test code runs fine on my
Mac.

Here are the diagnostic steps I followed:

1. Wrote a unit test to produce and then parse Date values
- copied the private UTC and GMT SimpleDateFormat members used by
MetaDataEntry
- PASSED
2. Wrote a unit test to parse the specific formatted date which was failing
- using the same SimpleDateFormat copies
- test string was "2007-11-07T22:45:08.577UTC"
- PASSED
3. Wrote a utility to parse the log files, checking the TimeStamp entries
4. Ran the utility against a local copy of
"385c7c019544dbe75736223ffd7ee18b872f6b08_log.xml"
- uname -a =
Darwin Fatty-MacBook.local 8.11.1 Darwin Kernel Version 8.11.1:
Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
- java -version =
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
- PASSED
5. Altered the local copy to introduce an error in one of the TimeStamp
entries
- FAILED
6. Copied the utility to the test.sharedrecords.org
7. Ran the utility against the original copy of
"385c7c019544dbe75736223ffd7ee18b872f6b08_log.xml"
- uname -a =
Linux test 2.6.8-3-686 #1 Tue Dec 5 21:26:38 UTC 2006 i686 GNU/Linux
- java -version =
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian
4.1.1-20)
- FAILED on every entry

Some obvious questions:

Am I doing something wrong in my testing/debugging?
Did this ever work?
Has the date format changed?
Can the date format change?
What version of Java does everyone use for development?

I'm upgrading test.sharedrecords.org, bringing all the installed
packages to the current available versions and adding the non-free
category to get sun's official java implementation. There may be some
performance differences (better or worse), but at least we should get
compatibility within the standard library.

Any concerns?

-Andreas

ps. A small complaint about the related code in Shared Records:
try/catch clauses should not be used for normal control flow. You
shouldn't do anything within a catch that may itself fail, or that is
more than is necessary to recover from the exception. In this particular
case, after failing to parse a TimeStamp, a second attempt to parse the
TimeStamp in a different way is attempted, which then throws an uncaught
exception.

Martin Budden wrote:
> What's the solution to this? Do we need a restart? By the way, I'm not
> sure who is responsible for fixing this, is it Andreas or Cory?
>
> Martin
>
> On Dec 4, 2007 2:50 PM, Andreas Kollegger <and...@kollegger.name> wrote:
>
>> I noticed a few problems in the logs. There is a null-pointer problem
>> which I believe is a consequence of a previous failure to parse a badly
>> formatted date entry...
>>
>> java.text.ParseException: invalid Date syntax in
>> "2007-11-07T22:45:08.577UTC"
>>
>>
>>
>> Martin Budden wrote:
>>
>>> Andreas,
>>>
>>> I don't need anything on 8080.
>>>
>>> Any leads on why the annotations API at:
>>>
>>> http://test.sharedrecords.org:80/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08
>>>
>>> is not working?
>>>
>>> Martin
>>>
>>>
>>> On Dec 4, 2007 1:25 PM, Andreas Kollegger <and...@kollegger.name> wrote:
>>>
>>>
>>>> admin/una1mesa#
>>>>
>>>> Let me know if you need tomcat back on 8080 for some reason. I will then
>>>> move the MORE server to some other port.
>>>>
>>>> -Andreas
>>>>
>>>> Cory Zue wrote:
>>>>
>>>>
>>>>> You are correct. BTW just realized that you can do this to view all
>>>>> the metadata instead of mucking around in that app i sent you:
>>>>>
>>>>> http://test.sharedrecords.org/records?prefix=385c7c019544dbe75736223ffd7ee18b872f6b08/log/&format=json
>>>>> <http://test.sharedrecords.org/records?prefix=385c7c019544dbe75736223ffd7ee18b872f6b08/log/&format=json>
>>>>>
>>>>> I can't do anything about the annotation server w/o the tomcat
>>>>> password, but it seems like it's got to be a config issue
>>>>>
>>>>> On 12/4/07, *Martin Budden* <mjbu...@gmail.com
>>>>> <mailto:mjbu...@gmail.com>> wrote:
>>>>>
>>>>> Well, a request to:
>>>>>
>>>>> http://test.sharedrecords.org:80/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08?format=json&attributes=all
>>>>> <http://test.sharedrecords.org:80/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08?format=json&attributes=all>
>>>>>
>>>>> redirects to:
>>>>>
>>>>> http://test.sharedrecords.org/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08?format=json&attributes=all
>>>>> <http://test.sharedrecords.org/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08?format=json&attributes=all>
>>>>>
>>>>> and then gives me a blank page
>>>>>
>>>>> Martin
>>>>>
>>>>> On Dec 4, 2007 11:06 AM, Cory Zue <cz...@dimagi.com
>>>>> <mailto:cz...@dimagi.com>> wrote:
>>>>> > Hi Martin,
>>>>> >
>>>>> > The servlet appears to be up, in that hitting:
>>>>> > http://test.sharedrecords.org/annotations/ is at least looking
>>>>> for a record
>>>>> > id. Is the metadata just not appearing properly? Andy switched
>>>>> the port to
>>>>> > 80 and deployed priya's code on 8080 which explains the second
>>>>> issue.
>>>>> >
>>>>> > Unfortunately I don't have access to the tomcat on that box
>>>>> (Andy can you
>>>>> > send me the password again?) so I can't try redeploying.
>>>>> >
>>>>> > -cory
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 12/4/07, Martin Budden <mjbu...@gmail.com
>>>>>
>>>>> <mailto:mjbu...@gmail.com>> wrote:
>>>>> > > Hi,
>>>>> > >
>>>>> > > I've been trying to do some tiddlywiki sharedrecords testing
>>>>> and am
>>>>> > > having some problems. In particular the
>>>>> > >
>>>>> > > http://test.sharedrecords.org/annotations/
>>>>> > >
>>>>> > > API does not seem to be working
>>>>> > >
>>>>> > > I've also noticed that:
>>>>> > >
>>>>> > >
>>>>> >
>>>>> http://test.sharedrecords.org:8080/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08
>>>>> <http://test.sharedrecords.org:8080/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08>
>>>>> > >
>>>>> > > returns a very odd:
>>>>> > >
>>>>> > >
>>>>> /home/priya/more/www/annotations/385c7c019544dbe75736223ffd7ee18b872f6b08
>>>>> > > not found
>>>>> > >
>>>>> > > which suggests something is not set up properly
>>>>> > >
>>>>> > > Martin
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Cory L. Zue
>>>>> > Chief Technology Officer
>>>>> > Dimagi, Inc | One Kendall Square | Bldg. 400, 4th
>>>>> Floor | Cambridge,
>>>>> > MA 02139
>>>>> > work: (617) 621 8595 x19 | cell: (617) 416 0544
>>>>> > http://www.dimagi.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cory L. Zue
>>>>> Chief Technology Officer
>>>>> Dimagi, Inc | One Kendall Square | Bldg. 400, 4th
>>>>> Floor | Cambridge, MA 02139
>>>>> work: (617) 621 8595 x19 | cell: (617) 416 0544
>>>>> http://www.dimagi.com/
>>>>>
>>>>>
>>

[Andreas Kollegger]

Following the install and switch to Sun's java 1.5.0, the metadata check
utility succeeds in verifying the timestamps.

I'm rebooting the server.

[Andreas Kollegger]

OK, the server has been rebooted and seems to be fine. Please let me
know of any general problems.

Martin, let me know if you are still experiencing any problems accessing
the annotations.

-Andreas