Re: 1st DNA container ever, need metadata contracts

Leo Simons <[email protected]> Sun, 04 Apr 2004 13:56:43 +0200
Newsgroups gmane.comp.java.jcontainer.interest
Message-ID <[email protected]>
[email protected] wrote:
> The website really doesn't describe any of the equirements for a DNA
> compatible container. It focuses on the demands of the component. Maybe we
> should describe some of the containers responsibilities for DNA components.

definately.

> IIRC dna-1.0 did not use MetaClass at all - subsequent rcs have used
> MetaClass in various guises and the latest release *should* use the latest
> release of metaclass.

dna-1.1-rc2 appears to work with metaclass-1.1-rc2 :D

>>   public static void verifySatisfiableDnaContract( Class type,
>>     ResourceLocator availableResources )
>>   {
>>     verifyDnaContract( type );
>>
>>     // TODO: what goes here?
> 
> You need to assert that the container can provide all resources that the
> component has declared it needs. .This means all resources defined as
> dependency, configuration data (that matches schema if appropriate)

the configuration one is difficult, as the acceptable formats are not 
specified. I assume you had something like spice configkit in mind 
here....I guess then the rule is that the container can't satisfy this 
contract if it doesn't support a particular schema type.

> and
> logger(s). The container must also ensure that the component will not be
> provided with resources if it has not declared the need for resource.

this is a "big one" for me as well :-D. I'm going to leave that for 
later. Also, this one seems very difficult to test in a TCK...there is 
simply no way to determine from the component side that the provided 
ResourceLocator contains only the declared materials.

> The
> coontainer must also ensure that any resources are "resolved" prior to the
> component using them (ie services have been initialized before being passed
> to component or JIT prior to first call).

This is one requirement that is not unique to DNA at all (a container 
just has to have a DAG or similar construct to do proper IoC), so I 
won't be testing it explicitly.

>>what do you think should be on the TODO lines? Should a utility class 
>>like this (all dna-compatible containers would need stuff like this) 
>>live in dna?
> 
> I can't think of a good way to implement any generic utility at this stage.

let's see what I come up with, and maybe we can move some things later...

> I have thought about writing a "generic" pico-like container (or even using
> pico) but that's not something that has been tackled yet.

hehehe. I did ;)

as always, updates visible pending the sf cvs lag...

-- 
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