Recent changes Microcontainer

[adrian.brock]

isAssignable/Progression

This logic needs moving into the TypeInfo abstraction, see the TODO
I added to the code. isProgression is just a special form isAssignable.

For now I've fixed the failing tests (that don't provide a classloader)
by stealing it from the bean's class.

Builder

I've refactored the builder so the main entry point is part of the spi.
I moved the implementation into its own package so it doesn't get confused
as implementation of the metadata itself.

I also removed the use of reflection and made the impl type safe.
We have to use reflection sometimes because we don't know the types
or "joinpoints" at compile time, but using reflection bypasses compiler checks
which means you only find out it is broken at runtime, so we should avoid it
where it is possible.

Finally, the builder needs some tests. One of my "laws of programming"
is "If it isn't tested, it doesn't work" :-)

[alesj]

isAssignable/Progression

This logic needs moving into the TypeInfo abstraction, see the TODO
I added to the code. isProgression is just a special form isAssignable.

For now I've fixed the failing tests (that don't provide a classloader)
by stealing it from the bean's class.

How do I get a TypeInfo from String typeName and ClassLoader in Configurator?

Configurator.isAssignable() ...

if (typeNames[j] != null)
{
 TypeInfo info = null; // TODO - use typeNames[j] and cl
 if (typeInfos[j].isAssignableFrom(info) == false)
 {
 return false;
 }
}

[alesj]

Using KernelConfigFactory to get KernelConfig (which can provide this)?

Putting KernelConfig instance into Configurator?
It's a 'loop' usage. Looks wrong.

I see we are already using KernelConfig as a parameter.
Doing it the same here (adding it as a parameter in resolveProperty method)?
If I do this (just tried), then almost every method in Configurator needs it. Yuck.

Any other ways / ideas?

[adrian.brock]

"alesj" wrote:
Using KernelConfigFactory to get KernelConfig (which can provide this)?

Putting KernelConfig instance into Configurator?
It's a 'loop' usage. Looks wrong.

I see we are already using KernelConfig as a parameter.
Doing it the same here (adding it as a parameter in resolveProperty method)?
If I do this (just tried), then almost every method in Configurator needs it. Yuck.

Any other ways / ideas?

It is the KernelConfigurator that has this information.

The problem is that the current code uses a static singleton as a delegate
AbstractKernelConfigurator -> Configurator
so one way to fix would be to move the code to the AbstractKernelConfigurator
that needs kernel specific config.

Perhaps a simpler solution is to expose the TypeInfoFactory on the TypeInfo interface.

You would then be able to do

TypeInfoFactory typeInfoFactory = beanInfo.getClassInfo().getTypeInfoFactory();
TypeInfo typeInfo = typeInfoFactory.getTypeInfo(name, classLoader);