avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [InfoMover] Implementing the Façade Block
Date Thu, 22 Aug 2002 17:08:02 GMT


Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>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:avalon-apps-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-apps-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>


Mime
View raw message