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