This are some ideas we are kind of throwing around for refactoring SQLUnit. To minimize inconvenience we will do our refactoring on a branch and merge it back in to the head version once we are done.
Here are some ideas from Ivan and me. Feel free to add to these, or if you feel something is a bad idea, let us know what and why.
1) The SQLUnit engne should fire events to listeners. Each listener would represent a particular action tag, such as echo and test. So for example, the engine encounters a echo tag and fires an ECHO event to the EchoListener which will do what is needed to echo the output.
2) Move the LOG.debug() call in all the methods out to an aspect. This will make sure we get the full trace when we want one, not the methods where I remembered to put the LOG.debug() calls. This will also clean up the debug view somewhat so its simple to run.
3) Use an IoC container to capture all dependencies in a XML file before starting. Currently, SQLUnit works in "interpreter" mode, saving only the things it needs for the fiuture, such as Connection information. With this approach, we will read the XML file into the container and then start the container. This gives us the following advantages:
- Syntax errors in the XML file will be caught before a single test is executed, much like compiling a file and running.
- Less chance of null pointers, since we are going to make sure all our beans are fully formed before we proceed, or we get an error once we finish parsing the XML file.
- The XML file will be the "configuration" for the IoC container, SQLUnit provides an interface to load the container (I am looking at picocontainer) from the XML file and do a container.start().
4) Provide a Java API for running SQLUnit tests, something like a SqlUnitTest class which can be extended by people who wish to test their stored procedures without using an XML file. This is kind of linked with (3), since (3) will require us to bean-ify most of our tags, and being able to manipulate these beans programmatically is a natural by-product of that.
5) Move to Java 1.5 for the new refactored code. I have had reports of people talking about exceptions thrown when they compile with Java 1.5 JDK, so I know quite a few people are using it right now. The Java API will be usable with both Java 1.4 and Java 1.5 client code. Both for XML and Java API users, the only change they would need to make is to download the 1.5 JDK and point their JAVA_HOME to it instead of the 1.4.x JDK.
What do you think? Please provide feedback on this thread.
Thanks
Sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<quote>5) Move to Java 1.5 for the new refactored code.</quote>
We can port all code the JDK1.5. Recently I discovered I way to compile JDK1.5 code (one using generics, annotations and so on) to byte code executable by JDK1.4. The way is to provdide jsr14 value to -target option of JDK1.5 javac executable:
javac -target jsr14 <sources_goes_here>
I tried this with Sun's JDK1.5.
Regards
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2005-07-27
apropos this:
1) The SQLUnit engine should fire events to listeners. Each listener would represent a particular action tag, such as echo and test. So for example, the engine encounters a echo tag and fires an ECHO event to the EchoListener which will do what is needed to echo the output.
I'd suggest implementing it so any one action tag can have n many listeners. By default, SQLUnit would probably only have one listener per tag, but if you allow for plugging in custom listeners then people could easily extend SQLUnit with their own custom listeners.
In the above example, I could have the standard EchoListener and also have a custom EmailTimListener or whatever else I dream up listening to the same echo tag.
This is probably easy with listeners that don't have a side effect, like EchoListener. I'm not sure how well it would work with listeners that do have side effects. That would require some thought.
A more exotic use I could imagine is a custom listener that acts as a decorator to a statement tag. Maybe I'd put some kind of custom substitution language in my statement, then write a listener that executes before the standard StatementListener and reads the statement text, dynamically looks up a value in a database or whatever, then substitues what it looked up into the statement text to pass on to the StatementListener. The StatementListener wouldn't have to know that happened and would execute the statement text as normal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
This are some ideas we are kind of throwing around for refactoring SQLUnit. To minimize inconvenience we will do our refactoring on a branch and merge it back in to the head version once we are done.
Here are some ideas from Ivan and me. Feel free to add to these, or if you feel something is a bad idea, let us know what and why.
1) The SQLUnit engne should fire events to listeners. Each listener would represent a particular action tag, such as echo and test. So for example, the engine encounters a echo tag and fires an ECHO event to the EchoListener which will do what is needed to echo the output.
2) Move the LOG.debug() call in all the methods out to an aspect. This will make sure we get the full trace when we want one, not the methods where I remembered to put the LOG.debug() calls. This will also clean up the debug view somewhat so its simple to run.
3) Use an IoC container to capture all dependencies in a XML file before starting. Currently, SQLUnit works in "interpreter" mode, saving only the things it needs for the fiuture, such as Connection information. With this approach, we will read the XML file into the container and then start the container. This gives us the following advantages:
- Syntax errors in the XML file will be caught before a single test is executed, much like compiling a file and running.
- Less chance of null pointers, since we are going to make sure all our beans are fully formed before we proceed, or we get an error once we finish parsing the XML file.
- The XML file will be the "configuration" for the IoC container, SQLUnit provides an interface to load the container (I am looking at picocontainer) from the XML file and do a container.start().
4) Provide a Java API for running SQLUnit tests, something like a SqlUnitTest class which can be extended by people who wish to test their stored procedures without using an XML file. This is kind of linked with (3), since (3) will require us to bean-ify most of our tags, and being able to manipulate these beans programmatically is a natural by-product of that.
5) Move to Java 1.5 for the new refactored code. I have had reports of people talking about exceptions thrown when they compile with Java 1.5 JDK, so I know quite a few people are using it right now. The Java API will be usable with both Java 1.4 and Java 1.5 client code. Both for XML and Java API users, the only change they would need to make is to download the 1.5 JDK and point their JAVA_HOME to it instead of the 1.4.x JDK.
What do you think? Please provide feedback on this thread.
Thanks
Sujit
Hello Sujit,
<quote>5) Move to Java 1.5 for the new refactored code.</quote>
We can port all code the JDK1.5. Recently I discovered I way to compile JDK1.5 code (one using generics, annotations and so on) to byte code executable by JDK1.4. The way is to provdide jsr14 value to -target option of JDK1.5 javac executable:
javac -target jsr14 <sources_goes_here>
I tried this with Sun's JDK1.5.
Regards
Ivan
apropos this:
1) The SQLUnit engine should fire events to listeners. Each listener would represent a particular action tag, such as echo and test. So for example, the engine encounters a echo tag and fires an ECHO event to the EchoListener which will do what is needed to echo the output.
I'd suggest implementing it so any one action tag can have n many listeners. By default, SQLUnit would probably only have one listener per tag, but if you allow for plugging in custom listeners then people could easily extend SQLUnit with their own custom listeners.
In the above example, I could have the standard EchoListener and also have a custom EmailTimListener or whatever else I dream up listening to the same echo tag.
This is probably easy with listeners that don't have a side effect, like EchoListener. I'm not sure how well it would work with listeners that do have side effects. That would require some thought.
A more exotic use I could imagine is a custom listener that acts as a decorator to a statement tag. Maybe I'd put some kind of custom substitution language in my statement, then write a listener that executes before the standard StatementListener and reads the statement text, dynamically looks up a value in a database or whatever, then substitues what it looked up into the statement text to pass on to the StatementListener. The StatementListener wouldn't have to know that happened and would execute the statement text as normal.