Emmanuel Lecharny wrote:
Ole Ersoy a écrit :
Well,
If you consider the server being left in an unrecoverable state due to
basic JNDI operations then that's a good move.
- Ole
Didn't you found that the cause was that there were some broken logic in
the test ? Here is your last comment :
Yes - I should have probably put a "Caution" around that statement. There was broken logic in the code the test was running that caused ObjectClass A not to be deleted before ObjectClass B. This then leads to the server being left in a state where JNDI operations on the context containing ObjectClass A and ObjectClass B will fail. For instance children of the context cannot be listed, etc. So the only way to recover is to reinstall the server.
"When the test runs it is supposed to delete ObjectClass A first, but
the logic was broken"
If you have a clear test case to demonstrate a problem in the server,
and not in your test, then repoen the issue, and attach the test case.
The test is referenced in this comment:
https://issues.apache.org/jira/browse/DIRSERVER-950#action_12500469
Sorry there were so many comments. Especially the first one :-). In the beginning I thought this might be a tricky thing to track down, so that wanted to make sure I captured as much information as possible. I think if the server simply throws an exception when an attempt to delete a schema entry that has other schema entries dependent on it is made, it will solve the problem.
I may miss something, but consider that the initial JIRA and the added
comments didn't help at all to understand where the problem is.
Sure - Sorry - I should have documented more clearly in the end. Initially I
just noticed that I had to reinstall the server in order to recover, so I
wanted to capture all the symptoms around the process, before I attempted to
isolate. I'm changing things on my system so fast that occasionally recovering
the original state is very tricky. This way at least there was something.
I'll try to do it more cleanly though.
Thanks,
- Ole
