You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2007/08/09 18:46:48 UTC
[2.0] Changes to revision control
Hi Lenya devs,
as you may have noticed, I did a quite large commit to the revision
control infrastructure. The reason for this is that the former
implementation was not thread safe. This caused various
synchronization errors (ConcurrentModificationException etc.) when
running load tests with multiple threads.
A short overview of my changes:
* Refactored XML handling in SourceNodeRCML. Instead of reading/writing
the XML document for each operation, the list of entries is now loaded
one and only converted to XML when the RCML is written.
* SourceNodeRCMLs are now singletons per source URI, i.e. for each
source URI only one RCML object is created. This allows to synchronize
access to the RCML methods, avoiding concurrent modifications.
* Check-Out is now per session and not per user, i.e. you won't run
into trouble if you have two browser windows open.
The changes may seem fundamental because of the large commit, but in
fact most changes are refactoring and the addition of synchronization
facilities. The RCML interface has changed a bit, but since it is not
supposed to be called by client code, but rather from the repository
node implementations, this shouldn't cause any incompatibilities.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Jörn Nettingsmeier schrieb:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier schrieb:
>>>
>>>> Andreas Hartmann wrote:
>>>>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for
>>>>>> each source URI only one RCML object is created. This allows to
>>>>>> synchronize access to the RCML methods, avoiding concurrent
>>>>>> modifications.
>>>> let me see if i'm getting this: a source URI is a uuid? or a uuid
>>>> plus language? or uuid plus language plus revision? no, the last
>>>> wouldn't make sense... can you elaborate?
>>> ATM source URIs are lenya:// URIs. E.g., the sitetree has a source URI
>>> which doesn't contain a UUID.
>> ah, so the revision controller still uses the old repository access
>> based on the sitetree path...
>
> Actually it's not old - it's the normal way to access repository nodes.
Sorry - to avoid any misunderstandings: The lenya:// protocol doesn't
refer to sitetree paths, but to source paths (corresponding to file
system paths).
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>
>>> Andreas Hartmann wrote:
>>
>>>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for
>>>>> each source URI only one RCML object is created. This allows to
>>>>> synchronize access to the RCML methods, avoiding concurrent
>>>>> modifications.
>>> let me see if i'm getting this: a source URI is a uuid? or a uuid
>>> plus language? or uuid plus language plus revision? no, the last
>>> wouldn't make sense... can you elaborate?
>>
>> ATM source URIs are lenya:// URIs. E.g., the sitetree has a source URI
>> which doesn't contain a UUID.
>
> ah, so the revision controller still uses the old repository access
> based on the sitetree path...
Actually it's not old - it's the normal way to access repository nodes.
> so iiuc, in terms of the new repository
> api, we have one SouceNodeRCML per uuid per language. which implies that
> users can work on different translations of the same document
> concurrently. nice.
Yes, but this was already possible before the change.
>>> what happens to other sessions that want to commit? do they spin,
>>> or are they being notified, or does the user see an error and is
>>> prompted to retry?
>>
>> They are just blocked by the JVM.
>
> ah, nice. in unix terms, that would mean they are not spinning (polling
> regularly), but go to sleep and are only re-activated when the resource
> is available again... so it's easy on server resources.
Yes, I guess so - but actually I have no idea what the JVM exactly does.
But since synchronization is a quite common concept in Java, I guess
there is some kind of optimization :)
>
>> Committing a session should usually
>> be a matter of some milliseconds, so the user shouln't notice. It
>> can happen in high load conditions, though.
>
> well, as long as the user is not forced to do something special to fix
> it, it's fine. waiting a second is ok imho (for now - eventually we'll
> have to tune lenya for speed, but certainly not now :)
The synching happens only when a session is committed, which will
probably occur very rarely in user-driven environments.
>> I know this isn't the
>> most elegant approach, but in this area we should go for the safest
>> solution. Synchronization issues in the commit stage can lead to an
>> inconsistent repository (which occured during my load tests).
>
> i like it. it's safe, non-intrusive and easy to verify, which is good.
> from your first comment, i wasn't sure if you just were just making it
> fail like the indexing, and the user would have to take some action...
>
> thanks for your comments,
Thank you too for forcing me to clarify :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>
>> Andreas Hartmann wrote:
>
>>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for
>>>> each source URI only one RCML object is created. This allows to
>>>> synchronize access to the RCML methods, avoiding concurrent
>>>> modifications.
>> let me see if i'm getting this: a source URI is a uuid? or a uuid
>> plus language? or uuid plus language plus revision? no, the last
>> wouldn't make sense... can you elaborate?
>
> ATM source URIs are lenya:// URIs. E.g., the sitetree has a source
> URI which doesn't contain a UUID.
ah, so the revision controller still uses the old repository access
based on the sitetree path... so iiuc, in terms of the new repository
api, we have one SouceNodeRCML per uuid per language. which implies that
users can work on different translations of the same document
concurrently. nice.
>> what happens to other sessions that want to commit? do they spin,
>> or are they being notified, or does the user see an error and is
>> prompted to retry?
>
> They are just blocked by the JVM.
ah, nice. in unix terms, that would mean they are not spinning (polling
regularly), but go to sleep and are only re-activated when the resource
is available again... so it's easy on server resources.
> Committing a session should usually
> be a matter of some milliseconds, so the user shouln't notice. It
> can happen in high load conditions, though.
well, as long as the user is not forced to do something special to fix
it, it's fine. waiting a second is ok imho (for now - eventually we'll
have to tune lenya for speed, but certainly not now :)
> I know this isn't the
> most elegant approach, but in this area we should go for the safest
> solution. Synchronization issues in the commit stage can lead to an
> inconsistent repository (which occured during my load tests).
i like it. it's safe, non-intrusive and easy to verify, which is good.
from your first comment, i wasn't sure if you just were just making it
fail like the indexing, and the user would have to take some action...
thanks for your comments,
jörn
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Jörn Nettingsmeier schrieb:
>
>> Andreas Hartmann wrote:
>
>>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
>>>> source URI only one RCML object is created. This allows to synchronize
>>>> access to the RCML methods, avoiding concurrent modifications.
>> let me see if i'm getting this: a source URI is a uuid? or a uuid plus
>> language? or uuid plus language plus revision? no, the last wouldn't
>> make sense... can you elaborate?
>
> ATM source URIs are lenya:// URIs. E.g., the sitetree has a source
> URI which doesn't contain a UUID.
>
>
>>>> * Check-Out is now per session and not per user, i.e. you won't run
>>>> into trouble if you have two browser windows open.
>> makes sense.
>>
>>> Another one:
>>>
>>> * UnitOfWorkImpl.commit()/rollback() are now locked via the class
>>> object. This means that only one session can be committed at a time.
>>> Before, there have been exceptions ("... has been checked out by another
>>> user") when running the load tests and two sessions were committed at
>>> the same time.
>> a lock in the class object? that means a global lock iiuc.
>
> Yes.
>
>> what happens
>> to other sessions that want to commit? do they spin, or are they being
>> notified, or does the user see an error and is prompted to retry?
>
> They are just blocked by the JVM. Committing a session should usually
> be a matter of some milliseconds, so the user shouln't notice. It can
> happ
Ooops :)
It can happen in high load conditions, though.
-- Andreas
> I know this isn't the most elegant approach, but in this area we should
> go for the safest solution. Synchronization issues in the commit stage
> can lead to an inconsistent repository (which occured during my load
> tests).
>
> -- Andreas
>
>> (i
>> know, i should read the code, but it's quite a chunk, and i'm up to
>> other things atm - still trying to get a proxy test environment up...)
>>
>>
>> thanks,
>>
>> jörn
>>
>>
>
>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>>> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
>>> source URI only one RCML object is created. This allows to synchronize
>>> access to the RCML methods, avoiding concurrent modifications.
>
> let me see if i'm getting this: a source URI is a uuid? or a uuid plus
> language? or uuid plus language plus revision? no, the last wouldn't
> make sense... can you elaborate?
ATM source URIs are lenya:// URIs. E.g., the sitetree has a source
URI which doesn't contain a UUID.
>>> * Check-Out is now per session and not per user, i.e. you won't run
>>> into trouble if you have two browser windows open.
>
> makes sense.
>
>> Another one:
>>
>> * UnitOfWorkImpl.commit()/rollback() are now locked via the class
>> object. This means that only one session can be committed at a time.
>> Before, there have been exceptions ("... has been checked out by another
>> user") when running the load tests and two sessions were committed at
>> the same time.
>
> a lock in the class object? that means a global lock iiuc.
Yes.
> what happens
> to other sessions that want to commit? do they spin, or are they being
> notified, or does the user see an error and is prompted to retry?
They are just blocked by the JVM. Committing a session should usually
be a matter of some milliseconds, so the user shouln't notice. It can
happ
I know this isn't the most elegant approach, but in this area we should
go for the safest solution. Synchronization issues in the commit stage
can lead to an inconsistent repository (which occured during my load
tests).
-- Andreas
> (i
> know, i should read the code, but it's quite a chunk, and i'm up to
> other things atm - still trying to get a proxy test environment up...)
>
>
> thanks,
>
> jörn
>
>
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Jörn Nettingsmeier <ne...@apache.org>.
hi andreas!
Andreas Hartmann wrote:
> Andreas Hartmann schrieb:
>> Hi Lenya devs,
>>
>> as you may have noticed, I did a quite large commit to the revision
>> control infrastructure. The reason for this is that the former
>> implementation was not thread safe. This caused various
>> synchronization errors (ConcurrentModificationException etc.) when
>> running load tests with multiple threads.
wow. you've been busy! thanks for your work.
>> A short overview of my changes:
>>
>> * Refactored XML handling in SourceNodeRCML. Instead of reading/writing
>> the XML document for each operation, the list of entries is now loaded
>> one and only converted to XML when the RCML is written.
neat.
>> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
>> source URI only one RCML object is created. This allows to synchronize
>> access to the RCML methods, avoiding concurrent modifications.
let me see if i'm getting this: a source URI is a uuid? or a uuid plus
language? or uuid plus language plus revision? no, the last wouldn't
make sense... can you elaborate?
>> * Check-Out is now per session and not per user, i.e. you won't run
>> into trouble if you have two browser windows open.
makes sense.
> Another one:
>
> * UnitOfWorkImpl.commit()/rollback() are now locked via the class
> object. This means that only one session can be committed at a time.
> Before, there have been exceptions ("... has been checked out by another
> user") when running the load tests and two sessions were committed at
> the same time.
a lock in the class object? that means a global lock iiuc. what happens
to other sessions that want to commit? do they spin, or are they being
notified, or does the user see an error and is prompted to retry? (i
know, i should read the code, but it's quite a chunk, and i'm up to
other things atm - still trying to get a proxy test environment up...)
thanks,
jörn
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> as you may have noticed, I did a quite large commit to the revision
> control infrastructure. The reason for this is that the former
> implementation was not thread safe. This caused various
> synchronization errors (ConcurrentModificationException etc.) when
> running load tests with multiple threads.
>
> A short overview of my changes:
>
> * Refactored XML handling in SourceNodeRCML. Instead of reading/writing
> the XML document for each operation, the list of entries is now loaded
> one and only converted to XML when the RCML is written.
>
> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
> source URI only one RCML object is created. This allows to synchronize
> access to the RCML methods, avoiding concurrent modifications.
>
> * Check-Out is now per session and not per user, i.e. you won't run
> into trouble if you have two browser windows open.
Another one:
* UnitOfWorkImpl.commit()/rollback() are now locked via the class
object. This means that only one session can be committed at a time.
Before, there have been exceptions ("... has been checked out by another
user") when running the load tests and two sessions were committed at
the same time.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> as you may have noticed, I did a quite large commit to the revision
> control infrastructure. The reason for this is that the former
> implementation was not thread safe. This caused various
> synchronization errors (ConcurrentModificationException etc.) when
> running load tests with multiple threads.
FYI - I have just run the load test with 20 concurrent threads
without any exceptions in the log.
The message "... was modified after it has been locked." can't be
avoided when allowing concurrent access to the web interface.
I'll do some more hands-on testing tomorrow to see if any
regressions occured.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Hi Richard,
>
> Richard Frovarp schrieb:
>
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> as you may have noticed, I did a quite large commit to the revision
>>> control infrastructure. The reason for this is that the former
>>> implementation was not thread safe. This caused various
>>> synchronization errors (ConcurrentModificationException etc.) when
>>> running load tests with multiple threads.
>>>
>
> [...]
>
>
>> So, we did training with 20 people in the room today. I was using an
>> older build and ran into major problems with concurrency issues on the
>> sitetree. Directories being created without the nodes in the sitetree.
>> Directories being moved to trash without the entries being removed from
>> the sitetree. I am hoping that these fixes you've done clear up that issue?
>>
>
> I'm still on it, the issue is rather complex.
> You don't happen to have the logfile of your testing session, do you?
> That could be very helpful to see which exceptions occured.
>
> -- Andreas
>
>
>
No I don't. I just looked and the process running Lenya didn't have
write permission to the log files.
I was also running into a massive memory leak. My guess is it was a
result of bad ehcache.xml settings. The JVM would run up to the maximum
memory, then just hang with massive CPU utilization. I'm guessing it was
trying to garbage collect but couldn't find anything to gc.
We're doing this again in a week.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Hi Richard,
Richard Frovarp schrieb:
> Andreas Hartmann wrote:
>> Hi Lenya devs,
>>
>> as you may have noticed, I did a quite large commit to the revision
>> control infrastructure. The reason for this is that the former
>> implementation was not thread safe. This caused various
>> synchronization errors (ConcurrentModificationException etc.) when
>> running load tests with multiple threads.
[...]
> So, we did training with 20 people in the room today. I was using an
> older build and ran into major problems with concurrency issues on the
> sitetree. Directories being created without the nodes in the sitetree.
> Directories being moved to trash without the entries being removed from
> the sitetree. I am hoping that these fixes you've done clear up that issue?
I'm still on it, the issue is rather complex.
You don't happen to have the logfile of your testing session, do you?
That could be very helpful to see which exceptions occured.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> as you may have noticed, I did a quite large commit to the revision
> control infrastructure. The reason for this is that the former
> implementation was not thread safe. This caused various
> synchronization errors (ConcurrentModificationException etc.) when
> running load tests with multiple threads.
>
> A short overview of my changes:
>
> * Refactored XML handling in SourceNodeRCML. Instead of reading/writing
> the XML document for each operation, the list of entries is now loaded
> one and only converted to XML when the RCML is written.
>
> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
> source URI only one RCML object is created. This allows to synchronize
> access to the RCML methods, avoiding concurrent modifications.
>
> * Check-Out is now per session and not per user, i.e. you won't run
> into trouble if you have two browser windows open.
>
>
> The changes may seem fundamental because of the large commit, but in
> fact most changes are refactoring and the addition of synchronization
> facilities. The RCML interface has changed a bit, but since it is not
> supposed to be called by client code, but rather from the repository
> node implementations, this shouldn't cause any incompatibilities.
>
> -- Andreas
>
>
>
So, we did training with 20 people in the room today. I was using an
older build and ran into major problems with concurrency issues on the
sitetree. Directories being created without the nodes in the sitetree.
Directories being moved to trash without the entries being removed from
the sitetree. I am hoping that these fixes you've done clear up that issue?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Aug 9, 2007 um 20:09 schrieb Richard Frovarp:
> Andreas Hartmann wrote:
>> Hi Lenya devs,
>>
>> as you may have noticed, I did a quite large commit to the revision
>> control infrastructure. The reason for this is that the former
>> implementation was not thread safe. This caused various
>> synchronization errors (ConcurrentModificationException etc.) when
>> running load tests with multiple threads.
>>
>> A short overview of my changes:
>>
>> * Refactored XML handling in SourceNodeRCML. Instead of reading/
>> writing
>> the XML document for each operation, the list of entries is now
>> loaded
>> one and only converted to XML when the RCML is written.
>>
>> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
>> source URI only one RCML object is created. This allows to
>> synchronize
>> access to the RCML methods, avoiding concurrent modifications.
>>
>> * Check-Out is now per session and not per user, i.e. you won't run
>> into trouble if you have two browser windows open.
>>
>>
>> The changes may seem fundamental because of the large commit, but in
>> fact most changes are refactoring and the addition of synchronization
>> facilities. The RCML interface has changed a bit, but since it is not
>> supposed to be called by client code, but rather from the repository
>> node implementations, this shouldn't cause any incompatibilities.
>>
>> -- Andreas
>>
>>
>>
>
> There is a problem with these changes. You can't open a checked out
> page, unless you have the correct session. With no way to release
> the lock, any page that is locked and not properly unlocked by the
> user will remain locked. Before you could always get the user to
> login, hit edit, then cancel to release the lock. Now there is now
> way at all to do this.
A possible fix (also to avoid having to tell a user to login and
«pseudo-checkout-again» a page) could be to add a check when a
document is accessed if the user that checked out the locked document
is still logged in; if not the lock can probably safely be released.
Jürgen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Andreas Hartmann <an...@apache.org>.
Richard Frovarp schrieb:
> Andreas Hartmann wrote:
>> * Check-Out is now per session and not per user, i.e. you won't run
>> into trouble if you have two browser windows open.
[...]
> There is a problem with these changes. You can't open a checked out
> page, unless you have the correct session. With no way to release the
> lock, any page that is locked and not properly unlocked by the user will
> remain locked. Before you could always get the user to login, hit edit,
> then cancel to release the lock. Now there is now way at all to do this.
Yes, sorry that I didn't mention this yet. I'm currently working at it
and will probably commit it tomorrow.
Thanks for your comment,
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.0] Changes to revision control
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> as you may have noticed, I did a quite large commit to the revision
> control infrastructure. The reason for this is that the former
> implementation was not thread safe. This caused various
> synchronization errors (ConcurrentModificationException etc.) when
> running load tests with multiple threads.
>
> A short overview of my changes:
>
> * Refactored XML handling in SourceNodeRCML. Instead of reading/writing
> the XML document for each operation, the list of entries is now loaded
> one and only converted to XML when the RCML is written.
>
> * SourceNodeRCMLs are now singletons per source URI, i.e. for each
> source URI only one RCML object is created. This allows to synchronize
> access to the RCML methods, avoiding concurrent modifications.
>
> * Check-Out is now per session and not per user, i.e. you won't run
> into trouble if you have two browser windows open.
>
>
> The changes may seem fundamental because of the large commit, but in
> fact most changes are refactoring and the addition of synchronization
> facilities. The RCML interface has changed a bit, but since it is not
> supposed to be called by client code, but rather from the repository
> node implementations, this shouldn't cause any incompatibilities.
>
> -- Andreas
>
>
>
There is a problem with these changes. You can't open a checked out
page, unless you have the correct session. With no way to release the
lock, any page that is locked and not properly unlocked by the user will
remain locked. Before you could always get the user to login, hit edit,
then cancel to release the lock. Now there is now way at all to do this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org