Ok, I tried, and it failed.
Yes - This is great. It's supposed to fail. Now the server will be in the state described.
Did you look in LS and try to delete/refresh the entry I described?
I'm still working on my svn skills. I have an svn server setup and I'm going
to start running little tests to make sure I check in clean/minimal project
files.
This was just a quicky one time thing to make sure I captured the "Server
Breakage" scenario.
This is why the URL you gave is not a good idea... There is no way I can
run the test without a massive cleanup ...
Did you try:
mvn eclipse:clean elipse:eclipse
This should clean all the eclipse files and then regenerate them for your
system.
Sorry, it's in example.com. You have three sub-dirs, example, system and
schema. Simply remove the example.com directoy, the system and schema
directories will be recreated when the server will be restarted.
Awesome - I'm definitely putting that one in the "Little black book".
Thanks,
- Ole
Emmanuel Lecharny wrote:
=======================================================================
3) You pointed us to a test which is somewhere on the web. Don't do
that, it's not convenient, because your test will be very contextual.
Just attach the whole working test.
=======================================================================
Sure - I like quick self contained tests. In this case "The Whole
Working Test" is a fairly massive test setup, along with the test.
Therefore there is an option I would like us to consider because I
would have to invest a significant amount of time in translating the
"Massive test setup" into a single self contained test, in addition to
the 2-3 hours I spent documenting and isolating this thing. We could
do this:
svn co
https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/das.ldap.parent
das.ldap.parent
Ok, I tried, and it failed. This is one of the reason it's better to
attach a standalone test. Anyway, here are some comments about the test :
- you have injected .classpath and .project into SVN, and this is not a
good idea, as it may not be used directly on another version of eclipse.
I'ts better to use mvn eclipse:eclipse which will generate those files.
Moreover, those .classpath points to resources that are not loaded on my
computer (old versions of apacheds and shared), mvn would have
downloaded them.
- you are refering to incompatible versions of apacheds (namely, 1.0.).
This is not good
- you are also refering to a lot of eclipse plugin I don't have on my
eclipse installation (emf and xsd, using old versions of them).
This is why the URL you gave is not a good idea... There is no way I can
run the test without a massive cleanup ...
Import the child projects into eclipse. Run the test described. View
the context ou=objectClasses, cn=ecore, ou=schema in LS. Verify my
observation, being mainly that this context is now "Broken".
This should take about 2 minutes. If for some reason my observation
is missing come back to me and ask me to code a self contained test.
I think that what I explained in my previous point forbid me to run the
test without some more work, and it won't be 2 minutes for me to fix it
... I'm sorry about that !
I'll be happy to do it. Is this a fair request?
I's plain fair.
Ideally I think myself and the person fixing this would work together,
and come up with an integrated test suite targeted at keeping these
types of fixes fixed. If I code another test it could be that the
person I throw it over the wall to ends up recoding it anyways. I'll
be glad to help in any way I can, I just want us to be smart in terms
of how we work together.
The main problem is that when it comes to complex problems, you have to
factor of complexity :
- the potential bug in the server. If the bug does not occurs in very
specific circonstances, then writing a focused test is complex.
- the complexity of your code : it's always painfull to select the part
of it which demonstrates the error
Now, I would say that this is fair to ask the user to make the effort
first. The reason is that 99% of the cases, the error is hidden somwhere
in the user code. How many times did you heard about "damn <select you
favorite product/API>, it's fully buggy", and after a little
investigation, you discover that the error is in the client code ? We
see it all the times (just check MINA bug reports, it's always the same
thing :
"Q: there is a bug in MINA, blah blah blah..."
"A: Are you sure? Can you check that and that?"
"Q: Oh, well, that fixed the bug, I mean, it's working now ..."
We have bugs in the server, that's obvious. But if we have to spend some
time to check for every supposed bug, before discarding them, we won't
be able to fix any real bugs ... This is very true for complex tests.
This is the reason we ask users to do their homeworks before bringing
the problem to us, not because we are lazzy, but because of the lack of
time...
=======================================================================
Last thing : you don't have to reinstall the server : just delete the
data (a directory called example.com, or whatever name you gave to
your partition, plus the schema directory in server-work). It will do
the trick.
=======================================================================
Oh OK - I looked under apacheds-1.5.0/var...and did not see a
server-work... Also all the entries created by the test are under
ou=schema. Does this still apply? I'm guessing if I delete the
entire schema partition, the server will just recreate it when it
restarts?
Sorry, it's in example.com. You have three sub-dirs, example, system and
schema. Simply remove the example.com directoy, the system and schema
directories will be recreated when the server will be restarted.
Emmanuel
