On Friday 06 June 2008 18:01, Georg Ragaller wrote:
> @Rickard && @Niclas:
>
> When looking at ServiceDependencyResolver#resolveDependency there
> are 3 steps when resolving:
Which version are you talking about, since there is no
ServiceDependencyResolver class?
> 1. lookup from internal Map (Cache)
> 2. looking for a concrete class
> 3. looking for a composite
>
> So it seems for me, that your intention for step 2. was (may be long
> time ago) to allow concrete classes as services, but the block for 2. is
> missing a
>
> return resolution;
>
> statement. Or what is this block for then?
I think I know what you are referring to. It is possible to have;
public interface Habba
{
:
}
public interface HabbaService extends Habba, ServiceComposite
{}
and then do
@Service Habba habba;
What happens then is that "Habba" is used as a search key for any service
composites which implements "Habba" and with some applied visibility rules;
1. If there is exact ONE service composite implementing Habba in the
module, that instance is injected.
2. If there is ZERO service composites in the module, check in the Layer;
2.1 If there is exactly ONE service composite visible in the Layer
implementing "Habba", that instance is injected.
2.2 If there is ZERO service composites in the Layer, check the Layers
below;
2.2.1 If there is exactly ONE visible service composite in the
Layers below, that instance will be used.
3. Else throw an Exception.
> I still claim that the Energy4Java has a bug, because the field
> objectModelFactory is never assigned, but used in
> newObjectBuilderFactory(), which then later causes a
> NullPointerException in ObjectBuilderFactoryImpl#getObjectResolution.
> A
>
> this.objectModelFactory = objectModelFactory;
>
> at the end of the Energy4Java constructor should do that.
What version are we talking about here?
HEAD == unstable and can't do much right now.
0.2 should use the advised assembly mechanisms.
I doubt we will be able to provide support for bootstrap procedures other than
those we recommend. At least until this area is further solidified.
> I've added both lines above to my environment and my code with a
> concrete service class works as expected.
>
> A different version with a service as composite works only if I setup
> Energy4Java with my own CompositeRegistry and implement
> getCompositeType() accordingly, because the default CompositeRegistry,
> which is CompositeRegistryImpl is not really implemented.
We are far from allowing custom implementations of internals. The "delegate"
support in Energy4Java will be dropped "soon".
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
