pipeline using document() fails to release files?

[Lars Huttar <la...@sil.org>]

Hi all,
We suspect this is a bug but it's not clear whose.

The problem that occurs is that a certain file, iHub.xml, sometimes 
cannot be moved or removed under Windows, as if a user were editing it 
(no one is). Once this condition occurs, it persists until we shut down 
Tomcat. (The consequence is that certain automated procedures, like a 
Subversion update, get stuck or fail.)
The circumstances under which iHub.xml gets "stuck" seem to be after it 
gets referenced by a document() reference from an XSLT stylesheet run by 
Cocoon.
Apparently, Cocoon is locking iHub.xml and not letting it go when it should.
Has anyone else encountered this?

Thanks,
Lars

P.S.
We realize document() is not recommended under Cocoon because of caching 
issues, but I thought as long as we took into account potential problems 
with caching, we could go ahead and use document(). Using document() 
instead of cinclude does make things a lot simpler for our application.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: pipeline using document() fails to release files?

[Gerald Aichholzer <ga...@iicm.edu>]

Hi,

Lars Huttar wrote:
> Hi all,
> We suspect this is a bug but it's not clear whose.
> 
> The problem that occurs is that a certain file, iHub.xml, sometimes 
> cannot be moved or removed under Windows, as if a user were editing it 
> (no one is). Once this condition occurs, it persists until we shut down 
> Tomcat. (The consequence is that certain automated procedures, like a 
> Subversion update, get stuck or fail.)
> The circumstances under which iHub.xml gets "stuck" seem to be after it 
> gets referenced by a document() reference from an XSLT stylesheet run by 
> Cocoon.
> Apparently, Cocoon is locking iHub.xml and not letting it go when it 
> should.
> Has anyone else encountered this?
> 

I have experienced the same problems once (i.e. it was impossible
to edit a file used by the document() function). I think it is a
Cocoon related problem because I am working with Jetty.

I didn't solve the problem because I found a more elegant solution
using map:aggregate and a XSLT stylesheet afterwards.


Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: pipeline using document() fails to release files?

[Antonio Gallardo <ag...@agssa.net>]

Hi Lars:

I suspect this is a know xalan bug. But nor 100% sure. Try saxon.

Best Regards,

Antonio Gallardo.

Lars Huttar wrote:

> Hi all,
> We suspect this is a bug but it's not clear whose.
>
> The problem that occurs is that a certain file, iHub.xml, sometimes 
> cannot be moved or removed under Windows, as if a user were editing it 
> (no one is). Once this condition occurs, it persists until we shut 
> down Tomcat. (The consequence is that certain automated procedures, 
> like a Subversion update, get stuck or fail.)
> The circumstances under which iHub.xml gets "stuck" seem to be after 
> it gets referenced by a document() reference from an XSLT stylesheet 
> run by Cocoon.
> Apparently, Cocoon is locking iHub.xml and not letting it go when it 
> should.
> Has anyone else encountered this?
>
> Thanks,
> Lars
>
> P.S.
> We realize document() is not recommended under Cocoon because of 
> caching issues, but I thought as long as we took into account 
> potential problems with caching, we could go ahead and use document(). 
> Using document() instead of cinclude does make things a lot simpler 
> for our application.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org