Berin Loritsch wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Berin Loritsch wrote:
I am glad things start up OK, but how do I set up the Connection and then test that it handles it OK?I really have not thought about this a great deal - so this is off the top of my head .... (a) create a client componet - declare it as dependent on the server component (so the server will be launched whe the client request a refercence - or alternatively - declare the server as activation="true")., (b) in the initialize or start method of you client - invoke operations against the appropriate server.
Probems we have to deal with:
(a) Using a fixed version of Phoneix which includes the GenericBlockContext becuase your referencing resource that are Phoenix depedent which makes infomover phoenix dependent (see email to Paul on this topic) - also the fixed-Phoenix icludes Phoenix recognition of .xtype meta-info (although in this demo I don't think that an issue)
(b) Using a fixed version of cornerstone that includes .xtype resorces so that Merlin can take care of the work around re. BlockContext stuff.
I can commit all of this to the Merlin lib and add the infomover.xml file to src/etc directory and you should be able to play from there.
Sound ok?
Sounds good to me.
It's done - all of the required jars are committed alonf with the infomover.xml file
http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/assembly/src/etc/infomover.xml
You should be able to execture it using te following commands:
$ cd <your merlin directory> $ merlin src\etc\infomover.xml
Let me know asap if there are any probems (if there are it will be requirement for the addition of .xtype descriptors to the infobuild.jar file - but I don't think this is necessaty).
This solution is a fundamental change from
the ExcaliburTestCase. The ExcaliburTestCase *was* the client, which
works really well for JUnit. Unfortunately in this case, I am not sure
that it is a good way to test the Phoenix blocks.
It should not be a problem - we can easily put in place a configuration for merlin that runs up a set of client componets. I'm assuming that things are basically going to give the same results under a common VM - i.e. hosting a clinet componet alongside a server component should return the sme results.
One question though, when you say "fixed version of Phoenix" what exactly do you mean? I don't want to develop against a fork--so it would have to be changes that are *in* the Phoenix CVS repository.
I suggest you raise this with the Phoeix developers - the details are covered in an email to Paul.
http://marc.theaimsgroup.com/?l=avalon-dev&m=102997523828896&w=2
I've included lots of comments in-line so you can see what's going on.
Just for reference - this is wequivalent to the Phoenix assembly, config and environment source all rolled into one.
We might have to have a different test framework for this.... If so, we might have to revive the "testlet" repository to be an extension of JUnit or something.
If we make the automated tests a Component that lives inside the containers, we can do something that is as easy to use as JUnit. What I want is something simple to write like this:
package org.apache.avalon.testlet;
import junit.framework.Assert;
public interface TestCase { void runTests(); }
public abstract class AbstractTestCase extends Assert implements TestCase { public void setUp() {} public void tearDown() {}
public void runTests() { setUp(); // perform all the complex reflection calls for every // "test" method tearDown(); } }
package org.apache.infomover.connection.test;
import org.apache.infomover.connection.*; import org.apache.infomover
public class ConnectionTestCase extends AbstractTestCase implements Serviceable { private ConnectionManager m_connections;
public void service( ServiceManager manager ) { m_connections = (ConnectionManager) manager.lookup( ConnectionManager.ROLE); }
public void testFoo() { // perform the required logic }
}
That's totally in sync with what I was thinking - make it "drop-dead-simple". Marioano Adolfo Nardi has offered to work on Melin unit tests - perhaps this would be an interesting direction?
Cheers, Steve.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
