You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Roland Porath <ro...@exari.com> on 2008/02/06 07:04:23 UTC
properties in collections
Started this thread in users but it's getting a bit nasty now:
We got jackrabbit 1.4 here and are running it as a webdav server.
When I try to add a property to a collection using PROPPATCH the new
property is not persisted. The modification date is update.
I looked at the ItemImpl.save method and noticed that if I update a property
on a collection I got two items of type PropertyState in the dirty list.
One is the new property one is the lastModified
So far so good, here's the catch
When I do the same thing on a non collection resource I get three items in
the list. Additional to the two guys mentioned above there is another one of
type NodeState.
Now this makes a lot of sense since if I add a property the parent gets
dirty.
Why does this not happen on collections?
There seems to be a difference in
SessionItemStateManager.getDescendantTransientItemStates
It is my impression that the node id passed in is not the parent but the
node itself if it's a collection but I might be barking up the wrong tree
here.
If adding a prop to a coll is something illegal (for a given config) why is
no exception thrown or no error logged?
I did make some changes to the node config that should allow for props on
colls.
And now the big one: what do I need to do to make the problem go away?
Any help will be greatly appreciated
Cheers
roland
RE: properties in collections; nailed the bastard
Posted by Roland Porath <ro...@exari.com>.
> -----Original Message-----
> From: Angela Schreiber [mailto:anchela@day.com]
> Sent: Thursday, 7 February 2008 8:24 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: properties in collections; nailed the bastard
>
> hi roland
>
> thanks for the great summary in the post before.
>
> Roland Porath wrote:
> > Seems I found the issue;
>
> cool.
>
> > Jackrabbit persists the properties just fine; it was just the export
> handler
> > (DirListingExportHandler) that has a hardcoded list of properties to be
> > exported.
>
> > Got a hack now that works and will write a new handler class that is
> > suitable for Webdav users and send it to this mailing list.
>
> if you want to contribute that, feel free to attach it
> to an issue... (i will create one).
Will do.
>
> the actually issue is from my point of view:
> DirListingExportHandler should not implement PropertyHandler
> at all. it's only use is to display a nice HTML page in case
> the collection is requested using GET.
> It should not deal with PROPFIND at all...
That sounds like a good idea and it explains a number of things in that
class. The current DirListingExportHandler has a large section devoted to
handling properties which should be it's own class
(WebDAVCollectionPropertyExportHandler seems like a nice and descriptive
name)
Is that what you mean?
I assume that also means taking the DirListingExportHandler out of the
<propertymanager> in config.xml and replacing it with the
WebDAVCollectionPropertyExportHandler
>
> I'm going to fix that.
>
> > Where is a good place to document things like this?
>
> I would state limitations in the JavaDoc and in the resource
> configuration... but maybe other would look for that in the
> Wiki? Don't know.
I'll put it in the WebDAV section of the wiki. Seems like the natural
habitat for that kind of information.
>
> > There might be more
> > people out there who fall into that trap. Well at least I hope I'm not
> the
> > only one. Would make me feel a bit stupid.
>
> oh no!
No worries. I'm used to it.
> please keep finding issues and writing your
> experiences to the list.
>
> angela
>
>
> !DSPAM:47aacdf655271608511473!
Re: properties in collections; nailed the bastard
Posted by Angela Schreiber <an...@day.com>.
hi roland
thanks for the great summary in the post before.
Roland Porath wrote:
> Seems I found the issue;
cool.
> Jackrabbit persists the properties just fine; it was just the export handler
> (DirListingExportHandler) that has a hardcoded list of properties to be
> exported.
> Got a hack now that works and will write a new handler class that is
> suitable for Webdav users and send it to this mailing list.
if you want to contribute that, feel free to attach it
to an issue... (i will create one).
the actually issue is from my point of view:
DirListingExportHandler should not implement PropertyHandler
at all. it's only use is to display a nice HTML page in case
the collection is requested using GET.
It should not deal with PROPFIND at all...
I'm going to fix that.
> Where is a good place to document things like this?
I would state limitations in the JavaDoc and in the resource
configuration... but maybe other would look for that in the
Wiki? Don't know.
> There might be more
> people out there who fall into that trap. Well at least I hope I'm not the
> only one. Would make me feel a bit stupid.
oh no!
please keep finding issues and writing your
experiences to the list.
angela
RE: properties in collections; nailed the bastard
Posted by Roland Porath <ro...@exari.com>.
Seems I found the issue;
Jackrabbit persists the properties just fine; it was just the export handler
(DirListingExportHandler) that has a hardcoded list of properties to be
exported. This list is identical to the properties you get on nt:folder in
the original configuration. So if you change the node-config you also need a
new property handler.
The issue with the "clean" collection apparently had to do with caching and
was just a distraction.
Got a hack now that works and will write a new handler class that is
suitable for Webdav users and send it to this mailing list.
Where is a good place to document things like this? There might be more
people out there who fall into that trap. Well at least I hope I'm not the
only one. Would make me feel a bit stupid.
Cheers
roland
> -----Original Message-----
> From: Roland Porath [mailto:roland@exari.com]
> Sent: Thursday, 7 February 2008 11:23 AM
> To: dev@jackrabbit.apache.org
> Subject: RE: properties in collections
>
> Hi Angela
>
> I apologise for being unclear in my original post.
>
> I did start from the webdav layer. Only when the behavior of that did not
> make sense to me I started to dig into the code of the server.
> I do appreciate that the server is at a much lower level than webdav but
> currently I believe this is where the problem originates.
>
> Just a brief recapitulation of the webdav behavior:
>
> All test were run with an unmodified config.xml
>
> Case 1 unpatched builtin-nodetypes.xml
> 1.1. non collection
> - proppatch returns a 207 containing a 200
> - propget returns the newly created property and it's value
> 1.2 collection
> - proppatch returns a 207 containing a 409
> Both 1.1 and 1.2 are exactly what you would expect.
> Case 2 patched builtin-nodetypes;
> 2.1 non collection:
> - same behavior as 1.1
> 2.1 collection:
> - proppatch return 207 containing a 200
> - propget does not return the newly created property but
> lastModified has been updated.
>
>
> That's where I was at when I decided I had to dig into the code and found
> that collections don't get dirty when a property is added.
> I guess what I'm trying to find out is if this is a feature or a bug.
> I need to fix this because we make heavy use of collections on properties.
> From your response I get the impression that you suspect it to be a bug
> and
> unless some new evidence comes in, I'll second that.
> Should it be bugged in JIRA? I'm happy to pick it up because I need to fix
> it asap anyway.
> The problem seems to live in the area of ItemImpl.save() and the whole
> persistence mechanism around it.
>
> Cheers
>
> Roland
>
> APPENDIX for the terminally geeky: protocol of my tests
>
> **************************************************************************
> **
> ********
> UNPATCHED BUILTIN-NODETYPES
> **************************************************************************
> **
> ********
> <nodeType name="nt:hierarchyNode" isMixin="false"
> hasOrderableChildNodes="false" primaryItemName="">
> <supertypes>
> <supertype>nt:base</supertype>
> </supertypes>
> <propertyDefinition name="jcr:created" requiredType="Date"
> autoCreated="true" mandatory="false" onParentVersion="INITIALIZE"
> protected="true" multiple="false"/>
> </nodeType>
>
> *************************NON
> COLLECTION********************************************
> cadaver: propset t1 testProp testvalue
>
> PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/t1 HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: cadaver/0.22.2 neon/0.24.6
> Connection: TE
> TE: trailers
> Content-Length: 208
> Content-Type: application/xml
> Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:">
> <D:set>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
> </D:prop>
> </D:set>
> </D:propertyupdate>
>
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 339
> Date: Wed, 06 Feb 2008 22:57:13 GMT
> Server: Apache-Coyote/1.1
>
> <?xml version="1.0" encoding="UTF-8"?>
> <D:multistatus xmlns:D="DAV:">
> <D:response>
>
> <D:href>http://127.0.0.1:5000/jackrabbit-webapp-
> 1.4/repository/default/test/
> t1</D:href>
> <D:propstat>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/"/>
> </D:prop>
> <D:status>HTTP/1.1 200 OK</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus>
>
> *************************COLLECTION***************************************
> **
> ***
> cadaver: propset c1 testProp testvalue
>
> PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/c1 HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: cadaver/0.22.2 neon/0.24.6
> Connection: TE
> TE: trailers
> Content-Length: 208
> Content-Type: application/xml
> Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:">
> <D:set>
> <D:prop>
> <testprop
> xmlns="http://webdav.org/cadaver/custom-properties/">value</testprop>
> </D:prop>
> </D:set>
> </D:propertyupdate>
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 346
> Date: Wed, 06 Feb 2008 23:01:21 GMT
> Server: Apache-Coyote/1.1
>
> <?xml version="1.0" encoding="UTF-8"?>
> <D:multistatus xmlns:D="DAV:">
> <D:response>
>
> <D:href>http://127.0.0.1:5000/jackrabbit-webapp-
> 1.4/repository/default/test/
> c1/</D:href>
> <D:propstat>
> <D:prop>
> <testprop
> xmlns="http://webdav.org/cadaver/custom-properties/"/>
> </D:prop>
> <D:status>HTTP/1.1 409 Conflict</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus>
>
>
>
>
>
>
>
> **************************************************************************
> **
> ********
> PATCHED BUILTIN-NODETYPES
> **************************************************************************
> **
> ********
> <nodeType name="nt:hierarchyNode" isMixin="false"
> hasOrderableChildNodes="false" primaryItemName="">
> <supertypes>
> <supertype>nt:base</supertype>
> </supertypes>
> <propertyDefinition name="jcr:created" requiredType="Date"
> autoCreated="true" mandatory="false" onParentVersion="INITIALIZE"
> protected="true" multiple="false"/>
> <propertyDefinition name="*" requiredType="undefined"
> autoCreated="false" mandatory="false" onParentVersion="COPY"
> protected="false" multiple="true"/>
> <propertyDefinition name="*" requiredType="undefined"
> autoCreated="false" mandatory="false" onParentVersion="COPY"
> protected="false" multiple="false"/>
> </nodeType>
> //tried the same patch in nt:folder; less evil hack i reckon,
> unfortunately
> same behavior.
> *************************NON
> COLLECTION********************************************
>
>
> PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/t1 HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: cadaver/0.22.2 neon/0.24.6
> Connection: TE
> TE: trailers
> Content-Length: 208
> Content-Type: application/xml
> Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:">
> <D:set>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
> </D:prop>
> </D:set>
> </D:propertyupdate>
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 339
> Date: Wed, 06 Feb 2008 23:31:28 GMT
> Server: Apache-Coyote/1.1
>
> <?xml version="1.0" encoding="UTF-8"?>
> <D:multistatus xmlns:D="DAV:">
> <D:response>
>
> <D:href>http://127.0.0.1:5000/jackrabbit-webapp-
> 1.4/repository/default/test/
> t1</D:href>
> <D:propstat>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/"/>
> </D:prop>
> <D:status>HTTP/1.1 200 OK</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus
>
>
> *************************COLLECTION***************************************
> **
> ***
>
>
> PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/c1 HTTP/1.1
> Host: 127.0.0.1:5000
> User-Agent: cadaver/0.22.2 neon/0.24.6
> Connection: TE
> TE: trailers
> Content-Length: 208
> Content-Type: application/xml
> Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:">
> <D:set>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
> </D:prop>
> </D:set>
> </D:propertyupdate>
>
>
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 340
> Date: Wed, 06 Feb 2008 23:28:08 GMT
> Server: Apache-Coyote/1.1
>
> <?xml version="1.0" encoding="UTF-8"?>
> <D:multistatus xmlns:D="DAV:">
> <D:response>
>
> <D:href>http://127.0.0.1:5000/jackrabbit-webapp-
> 1.4/repository/default/test/
> c1/</D:href>
> <D:propstat>
> <D:prop>
> <testProp
> xmlns="http://webdav.org/cadaver/custom-properties/"/>
> </D:prop>
> <D:status>HTTP/1.1 200 OK</D:status>
> </D:propstat>
> </D:response>
> </D:multistatus>
>
>
>
>
>
>
> !DSPAM:47aa4fd1151481528652890!
RE: properties in collections
Posted by Roland Porath <ro...@exari.com>.
Hi Angela
I apologise for being unclear in my original post.
I did start from the webdav layer. Only when the behavior of that did not
make sense to me I started to dig into the code of the server.
I do appreciate that the server is at a much lower level than webdav but
currently I believe this is where the problem originates.
Just a brief recapitulation of the webdav behavior:
All test were run with an unmodified config.xml
Case 1 unpatched builtin-nodetypes.xml
1.1. non collection
- proppatch returns a 207 containing a 200
- propget returns the newly created property and it's value
1.2 collection
- proppatch returns a 207 containing a 409
Both 1.1 and 1.2 are exactly what you would expect.
Case 2 patched builtin-nodetypes;
2.1 non collection:
- same behavior as 1.1
2.1 collection:
- proppatch return 207 containing a 200
- propget does not return the newly created property but
lastModified has been updated.
That's where I was at when I decided I had to dig into the code and found
that collections don't get dirty when a property is added.
I guess what I'm trying to find out is if this is a feature or a bug.
I need to fix this because we make heavy use of collections on properties.
>From your response I get the impression that you suspect it to be a bug and
unless some new evidence comes in, I'll second that.
Should it be bugged in JIRA? I'm happy to pick it up because I need to fix
it asap anyway.
The problem seems to live in the area of ItemImpl.save() and the whole
persistence mechanism around it.
Cheers
Roland
APPENDIX for the terminally geeky: protocol of my tests
****************************************************************************
********
UNPATCHED BUILTIN-NODETYPES
****************************************************************************
********
<nodeType name="nt:hierarchyNode" isMixin="false"
hasOrderableChildNodes="false" primaryItemName="">
<supertypes>
<supertype>nt:base</supertype>
</supertypes>
<propertyDefinition name="jcr:created" requiredType="Date"
autoCreated="true" mandatory="false" onParentVersion="INITIALIZE"
protected="true" multiple="false"/>
</nodeType>
*************************NON
COLLECTION********************************************
cadaver: propset t1 testProp testvalue
PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/t1 HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 208
Content-Type: application/xml
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
</D:prop>
</D:set>
</D:propertyupdate>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml;charset=UTF-8
Content-Length: 339
Date: Wed, 06 Feb 2008 22:57:13 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://127.0.0.1:5000/jackrabbit-webapp-1.4/repository/default/test/
t1</D:href>
<D:propstat>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/"/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
*************************COLLECTION*****************************************
***
cadaver: propset c1 testProp testvalue
PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/c1 HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 208
Content-Type: application/xml
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<testprop
xmlns="http://webdav.org/cadaver/custom-properties/">value</testprop>
</D:prop>
</D:set>
</D:propertyupdate>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml;charset=UTF-8
Content-Length: 346
Date: Wed, 06 Feb 2008 23:01:21 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://127.0.0.1:5000/jackrabbit-webapp-1.4/repository/default/test/
c1/</D:href>
<D:propstat>
<D:prop>
<testprop
xmlns="http://webdav.org/cadaver/custom-properties/"/>
</D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:propstat>
</D:response>
</D:multistatus>
****************************************************************************
********
PATCHED BUILTIN-NODETYPES
****************************************************************************
********
<nodeType name="nt:hierarchyNode" isMixin="false"
hasOrderableChildNodes="false" primaryItemName="">
<supertypes>
<supertype>nt:base</supertype>
</supertypes>
<propertyDefinition name="jcr:created" requiredType="Date"
autoCreated="true" mandatory="false" onParentVersion="INITIALIZE"
protected="true" multiple="false"/>
<propertyDefinition name="*" requiredType="undefined"
autoCreated="false" mandatory="false" onParentVersion="COPY"
protected="false" multiple="true"/>
<propertyDefinition name="*" requiredType="undefined"
autoCreated="false" mandatory="false" onParentVersion="COPY"
protected="false" multiple="false"/>
</nodeType>
//tried the same patch in nt:folder; less evil hack i reckon, unfortunately
same behavior.
*************************NON
COLLECTION********************************************
PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/t1 HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 208
Content-Type: application/xml
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
</D:prop>
</D:set>
</D:propertyupdate>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml;charset=UTF-8
Content-Length: 339
Date: Wed, 06 Feb 2008 23:31:28 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://127.0.0.1:5000/jackrabbit-webapp-1.4/repository/default/test/
t1</D:href>
<D:propstat>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/"/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus
*************************COLLECTION*****************************************
***
PROPPATCH /jackrabbit-webapp-1.4/repository/default/test/c1 HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 208
Content-Type: application/xml
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLmRvbQ==
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/">value</testProp>
</D:prop>
</D:set>
</D:propertyupdate>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml;charset=UTF-8
Content-Length: 340
Date: Wed, 06 Feb 2008 23:28:08 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://127.0.0.1:5000/jackrabbit-webapp-1.4/repository/default/test/
c1/</D:href>
<D:propstat>
<D:prop>
<testProp
xmlns="http://webdav.org/cadaver/custom-properties/"/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Re: properties in collections
Posted by Angela Schreiber <an...@day.com>.
hi roland
in order to simplify things let's try not to
mix various levels.
collections, proppatch is on the 'webdav-layer'
itemstates are deep in the jackrabbit core.
if you are dealing with the dav server you shouldn't
have to deal with the latter... and if you do, try to
forget about anything related to webdav. otherwise
it's very hard to follow you.
> When I try to add a property to a collection using PROPPATCH the new
> property is not persisted. The modification date is update.
maybe simply a bug?
can you please try the following:
- standard webdav resource config (config.xml) as shipped
with jackrabbit.
- debug what happens upon PROPPATCH on a collection.
if the collection is an nt:folder proppatch should always
fail within the PropertyHandler.importProperties call, since
there is no propertydefinition except the jcr:created which is
autocreated and protected.
if it fails: is the multistatus response correctly built?
-> if none of them. probably bug in the dav-server.
in a second step you may use your custom config/nodetypes.
basically the same applies here... try to isolate the problem in
terms of:
- is it a dav-server issue? (what exactly is the expected
outout. does the server code what it is expected to do?)
- do your custom nts behave as you expect them to?
(i.e. are you able to create the content expected to be
create by the dav-server using the jcr api?)
- finally, once the other sources have been excluded: what
exactly happens in the core.
> If adding a prop to a coll is something illegal (for a given config) why is
> no exception thrown or
the request should obviously not be successful.
either the multistatus should inform about what part
of the PROPPATCH failed (no exception) OR an exception
should be thrown... i.e. request failes with some 4XX
status code.
are you sure neither happens? then it's probably a
bug.
> no error logged?
maybe missing log output?
> I did make some changes to the node config that should allow for props on
> colls.
see answer on users-list.
> And now the big one: what do I need to do to make the problem go away?
see above.
> Any help will be greatly appreciated
hope it helped.
angela