Extending ExcaliburTestCase

[Giacomo Pati <gi...@apache.org>]

Hi all

I'd like to propose an extension to the ExcaliburTestCase class because we had
some proplems using it for Phoenix based Blocks.

First let me introduce how we develop Phoenix Services:

  1. Create an Avalon Component Role (Interface) to define the functionallity
used for a Service (we only use the Framework classes/interfaces).
  2. Create an implementation of the Role mentioned above.
  3. Create a Phoenix Service interface extending the Components Role and
eventually adding management functionallity.
  4. Create a Phoenix Block implementation by extending the Component
implementation and implementing the Service interface.

Using the ExcaliburTestCase we can easily test the Components. Now we got into
the problem that a Service we've written is using the masterstore from the
cornerstone project. These implementations do a down cast of the Context object
into a BlockContext object which the ExcaliburTestCase isn't able to deliver. 

So my proposal will be to extend the <context> part of the ExcaliburTestCase's
configuration file by adding some attributes to it which will:

  1. state what type of Context should be created (ie. type="block")
  2. have specific attributes/elements for specific types (ie. for BlockContext
populations like app-home, app-name, block-name, etc.)

Please feel free to forward this to other lists (ie. -apps, -phoenix, etc.).

What do you think about it?

Giacomo



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Extending ExcaliburTestCase

[Peter Donald <pe...@apache.org>]

On Tue, 30 Apr 2002 16:53, Giacomo Pati wrote:
> So my proposal will be to extend the <context> part of the
> ExcaliburTestCase's configuration file by adding some attributes to it
> which will:
>
>   1. state what type of Context should be created (ie. type="block")
>   2. have specific attributes/elements for specific types (ie. for
> BlockContext populations like app-home, app-name, block-name, etc.)
>
> Please feel free to forward this to other lists (ie. -apps, -phoenix,
> etc.).
>
> What do you think about it?

I like it. 

I have actually been thinking about doing something similar because I want to 
transport services between myrmidon, cocoon, phoenix and another app I got at 
work. However each has a slightly different container. What I was thinking 
was adding xdoclet tags to the contextualize methods of the services to do 
things like

/**
 * @av.context class=org.apache.avalon.phoenix.BlockContext
 * @av.context.entry key=mBeanServer class=javax.management.MBeanServer
 * @av.context.entry key=shared.classLoader class=java.lang.ClassLoader
 * @av.context.entry key=common.classLoader class=java.lang.ClassLoader
 */
public void contextualize( final Context c )
{
...
}

This says that the component must have 3 entrys in context with specific keys 
and types, and it also saids that the context must be an instance of 
BlockContext.

Of course at the moment the above would just be useful for documentation and 
automagically generating test scripts. However in the future I plan to add a 
section into BlockInfo descriptors that will actually verify that the above 
context is satisfied. (It will also allow blocks in phoenix to request other 
things like MBeanServer or services in myrmidon to access things like 
specific ClassLoaders).

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>