First again the posting I made some days before:
Form time to time magnolia runs into inconsistencies. This happens
mainly if you rename, move or copy nodes. The reason for that, is
that the user session doesn't get updated because it still has
pending changes where it shouldn't.
Normally you get this by concurrent editing or when a method
doesn't save all the nodes which it has changed.
This is very annoying and hard to debug, since you never know if
you are looking at a follow up problem. As a primar I changed the
WebContextImpl so that it checks on the first call (per request) to
the getHierarchyManager() method if the session has pending
changes. In standard magnolia this should never be the case, since
the changed data needs to get stored before returning the request.
If the session is changed the method logs an error and refreshes
the session. If you set the log into debug mode you will get a dump
of the changed nodes (this will be a hint for us).
Some of the wired problems went away after doing this, or could get
fixed.
If you use the jcr session in a way that doesn't allow this
behavior, please make a subclass and set it as the default
implementation in the mgnl-beans.properties.
As long the system behaves like this, it is in my point of view much
saver to keep this restrictive default implementation.
Since we made the architecture flexible enough, you can easily change
this (this was one of the main reason why we introduced this context
thing).
I found out why my regression tests were failing here. In
WebContextImpl, we now revert changes in the session, but I've been
using the session in our project here.
Meaning, we can edit, copy, create, delete nodes in session, and
then save or revert everything.
Given that there is very little chance of concurrency (in our
setup) I thought it was a valid feature.
Now, if we revert all the changes, this whole feature is going wrong.
At this time, I'm doing a custom build of magnolia, but, if
possible I would like to deal openly about it with other devs.
You can check in your WebContextImpl subclass, since other will like
to use it too.
In this case only the config in mgnl-beans.properties will differ in
your installation.
Is that practicable for you?
Philipp
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
