...except of course a cdl:system it is not, in fact it is one node under a system. Returning a system is not adequate, I am meant to strip out and return the first child of a system expected: <?xml version="1.0" encoding="UTF-8"?> <MyServer> <hostname>www.cddlm.org</hostname> <port>80</port> </MyServer> actual: <?xml version="1.0" encoding="UTF-8"?> <system xmlns="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0"> <MyServer xmlns=""> <hostname>localhost</hostname> <port>80</port> <hostname>www.cddlm.org</hostname> </MyServer> </system> junit.framework.ComparisonFailure: test []: Namespace URI inconsistent between {}MyServer and {http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0}system I seem to believe that cdl:system can have multiple nodes underneath. If I return a doc with a single root node, I can only test documents that have one thing to deploy, and so miss out on a whole suite of tests I propose that 1. the resolve() operation returns a document containing a cdl:system and all children 2. we retrofit the system wrapper to all existing CDL tests. -steve
Hi, in our existing JUnit tests regarding CDL resolution we usually consider all the resolved CDL, because we think it is interesting to test resolutions in the configuration part too, although they may not be used in the System part. I propose to return the cdl:cdl document in the resolve operation to explore more situations on the tests, but if you think just the system verification is enough, ok. In fact just considering the first child of a system is not good. Just another point: I did not understant what you meant by 2. we retrofit the system wrapper to all existing CDL tests. Regards, Ayla Steve Loughran wrote:
...except of course a cdl:system it is not, in fact it is one node under a system. Returning a system is not adequate, I am meant to strip out and return the first child of a system
expected: <?xml version="1.0" encoding="UTF-8"?> <MyServer> <hostname>www.cddlm.org</hostname> <port>80</port> </MyServer> actual: <?xml version="1.0" encoding="UTF-8"?> <system xmlns="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0"> <MyServer xmlns=""> <hostname>localhost</hostname> <port>80</port>
<hostname>www.cddlm.org</hostname> </MyServer> </system>
junit.framework.ComparisonFailure: test []: Namespace URI inconsistent between {}MyServer and {http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0}system
I seem to believe that cdl:system can have multiple nodes underneath. If I return a doc with a single root node, I can only test documents that have one thing to deploy, and so miss out on a whole suite of tests
I propose that 1. the resolve() operation returns a document containing a cdl:system and all children 2. we retrofit the system wrapper to all existing CDL tests.
-steve
Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:
Hi,
in our existing JUnit tests regarding CDL resolution we usually consider all the resolved CDL, because we think it is interesting to test resolutions in the configuration part too, although they may not be used in the System part.
I propose to return the cdl:cdl document in the resolve operation to explore more situations on the tests, but if you think just the system verification is enough, ok. In fact just considering the first child of a system is not good.
I think my resolution process can be fairly destructive on the configuration parts. Also, I only try and resolve stuff under system...other bits of the configuration I may or may not process. Since how we do that is out of scope of the spec, I dont think we can test it,
Just another point: I did not understant what you meant by 2. we retrofit the system wrapper to all existing CDL tests.
Yes, I realised that that was not needed. I thought I'd have to wrap everything underct:resolved in a cdl:system element, but that is needless, I can leave that alone. What I do have to do is assume that the response coming back from a resolve() operation is a cdl:system element, and compare all the stuff underneath. Have you tried using the test code yet? I must apologise for making lots of changes to it this week; it has been pretty unstable and one I make this next change everyone's code will have to change. Then I need to sit down and fix the failures that it is correctly showing up... -steve
Hi Steve, we have seen the test code, but have not started using it yet directly. So, from our part, feel free to change it, but please let us know when you finish these more recent changes so that we can use it avoiding rework. Another point, I always have problems trying to run the ant commands from the cddlm repository because everything is always missing in my machine and than I give up. I wanted to know what are the requirements for running the "ant all" or "ant test". I have ant 1.6.5, maven 2.0 and java 1.5. The current error I have is "Unable to find typedef schemavalidate". Do you know what may be missing? Thanks, Ayla Steve Loughran wrote:
Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:
Hi,
in our existing JUnit tests regarding CDL resolution we usually consider all the resolved CDL, because we think it is interesting to test resolutions in the configuration part too, although they may not be used in the System part.
I propose to return the cdl:cdl document in the resolve operation to explore more situations on the tests, but if you think just the system verification is enough, ok. In fact just considering the first child of a system is not good.
I think my resolution process can be fairly destructive on the configuration parts. Also, I only try and resolve stuff under system...other bits of the configuration I may or may not process. Since how we do that is out of scope of the spec, I dont think we can test it,
Just another point: I did not understant what you meant by 2. we retrofit the system wrapper to all existing CDL tests.
Yes, I realised that that was not needed. I thought I'd have to wrap everything underct:resolved in a cdl:system element, but that is needless, I can leave that alone. What I do have to do is assume that the response coming back from a resolve() operation is a cdl:system element, and compare all the stuff underneath.
Have you tried using the test code yet? I must apologise for making lots of changes to it this week; it has been pretty unstable and one I make this next change everyone's code will have to change. Then I need to sit down and fix the failures that it is correctly showing up...
-steve
Ayla Debora Dantas de Souza - Projeto Ourgrid wrote:
Hi Steve,
we have seen the test code, but have not started using it yet directly. So, from our part, feel free to change it, but please let us know when you finish these more recent changes so that we can use it avoiding rework.
OK. I think I have nearly finished. I've inevitably broken Jun's test run, so once we have that working as well then we could say things are stable. More changes -comparisons skip over xmlns declaratations -more context in error messages -added the cdl:system wrapper to every response (this was the easiest way of handling responses of >1 element in parallel) -fixed some quirks related to no namespace elements in xerces having a 'null' localname The main thing I've done is delve into the depths of junit and work out how it generates tests from methods, and have written the code to automatically turn every test document from a test catalog into its own test method, with its own success and failure. This is very nice for reporting; here is proof that the tests are successfully catching resolution failures in my code http://people.apache.org/~stevel/reports/org/smartfrog/test/unit/sfcore/lang... The goal for february will be to get the failure rate in this test suite from 100% to 0. as an aside, this is the first time that I've used the DOM java APIs for four years, I had forgotten how awful they are -they dont treat namespace declarations as special -you cant have an element or attribute outside a document -non-namespace behaviour != namespaced element behaviour -painful walking through children -so painful trying to create a parser, what with java endorsed directories. -etc etc. I would strongly discourage anyone from using it in their real code. JDom and Xom are both much better. Remember, Dom was originally written by netscape for javascript's use; then the w3c committees took it and defined it in IDL, C++ and Java. It predates xmlns, and it shows.
Another point, I always have problems trying to run the ant commands from the cddlm repository because everything is always missing in my machine and than I give up. I wanted to know what are the requirements for running the "ant all" or "ant test". I have ant 1.6.5, maven 2.0 and java 1.5. The current error I have is "Unable to find typedef schemavalidate". Do you know what may be missing?
you need an ant1.7alpha release: http://people.apache.org/~stevel/dist/ If its just the <schemavalidate> task (and it probably is), I could tune the build file to not bother validating xsd if the task is not found. As long as gump does it every night we can keep track on invalid documents without doing it every build.
participants (2)
-
Ayla Debora Dantas de Souza - Projeto Ourgrid
-
Steve Loughran