Re: DNA TCK?

peter-4lf8KW9E9MLMqX/[email protected] wrote:
> Well it is definetly something worth doing and FWIU it could easily be
> generalized to be a something that you could also use to unit test the
> Avalon stuff aswell if you are still involved with that. Anyways would be
> interesting to do and will gladly commit and help develope any stuff you
> contribute ;) I will also probably add an Avalon layer on top as we still
> need that for Loom.

Cool!

I'm even more ambitious: I want to use this stuff to test (most 
importantly, compliance with) potentially all IoC containers in existence :D

I've got step 0 in CVS:

   http://www.jroller.com/page/lsd/20040114

I'm not too happy about the invocation logging mechanism I've 
implemented, but I fail to see a better way. Right now, it basically 
works like this:

* an Invocation class (represents the method call of course)
* an InvocationLogger (stores invocations)
* an InvocationLoggerProvider (has a getInvocationLogger() method)
* an AbstractComponent class (implements InvocationLoggerProvider)
* each and every component we load up extends from AbstractComponent and
   each method we want to trace just logs manually, ie

                                                             // fragments
public abstract class AbstractBart extends AbstractComponent
     public final static Method swear;
     static
     {
         try
         {
             swear = AbstractBart.class
                 .getMethod( "swear", new Class[0] );
         }
         catch( NoSuchMethodException e )
         {
             throw new CascadingRuntimeException( e.getMessage(), e );
         }
     }
     public void swear()
     {
         super.log( swear );
     }

* the test code just casts components to InvocationLoggerProviders and
   retrieves the logs, ie

         InvocationLogger log = getLoggerFrom( script );
         List invocations = log.getInvocations();

         assertNotNull(
           invocations.get( findInvocation( log, "setHomer" ) ) );

but this is not exactly pretty, since I have to add loads of reflection 
statements everywhere.

However, I can't really think of a better way:

* Using proxy-based AOP or proxies themselves doesn't work (for example, 
all setXXX in abstract components would need to be public, which is no 
good for testing some types of IoC).

* Using bytecode modification requires control of the classloader (which 
the TCK ideally should not require, as many containers like having that 
control themselves)

* Using something like AspectJ seems a problem to me as well for much of 
the same reasons.

Could you take a look and perhaps think of something better?

If not, things can still proceed but it's a lot of manual labor :/
-- 
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett