Nabble - NanoContainer - PicoContainer - Users

Re: Java configurator

2008-12-02T08:01:33Z

This is really interesting. Glassfish and Derby are top rated
technologies for web apps, and to have some PicoContainer-leveraging
way of setting them up would be cool.

We have a Jetty binding ( https://svn.codehaus.org/picocontainer/java/2.x/trunk/jetty
). It is wedded to Jetty though with no abstraction that Tomcat or
Glassfish could take advantage of.

Tell us more, and introduce yourself a little :-)

Regards,

- Paul

On Dec 1, 2008, at 7:30 PM, devantor wrote:

> Hi, congrats for your project! I'm using pico to create a webapp
> with Derby and Glassfish embedded. I created a java configurator
> using annotations. My setup allows me to swap to another container.
> I use the factory and constructor pattern because I don't want to
> use @inject everywhere, the less intrusive the better.
>
> My project is using picocontainer snaphot with maven. I want to
> contribute the config part if it's useful for you.
>
>
> A file created in META-INF/dfxcontainer.
> properties setup the container factory to use.
> dfx
> .common
> .container.factory=dfx.common.container.ContainerFactoryTestImpl
>
> META-INF/dfxconfig.properties
> dfx.configs=dfx.common.config.Config1,dfx.common.config.Config2
>
> Examples:
>
> @DfxContainer(scope = ContainerScope1.class)
> public class Config1 implements DfxConfig {
>
> @DfxContainerComponent(key = ComponentA.class)
> public ComponentAImpl componentA;
>
> }
>
>
> @DfxComponent(id = "core-test")
> @DfxContainer(scope = ComponentScope.class)
> public class CoreTestConfig implements DfxConfig {
>
> @DfxContainerComponent(key = dfx.core.dao.DAOFacadeMock.class)
> public dfx.core.dao.DAOFacadeMock daoFacadeMock;
>
> @DfxContainerComponent(key =
> dfx.core.plugin.IndexerPluginTest.class)
> @DfxIndexerPlugin(extensions = { "extA", "extB" }, params = {
> @DfxParam(id = "paramA", values = { "valueA" }),
> @DfxParam(id = "paramB", values = { "valueB" }) },
> searchFields = {
> @DfxSearchField(value = "searchFieldA", visible = true),
> @DfxSearchField(value = "searchFieldB", visible =
> false) })
> public dfx.core.plugin.IndexerPluginTest indexerPluginTest;
>
> }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: BasicComponentParameter doesn't work with parameterized types

2008-12-02T07:49:45Z

Yeah, you'll most likely have to make that anon-inner class non-anon,
and make it public. There's a dumbass JVM rule about methods being
inaccessible despite being public if the class containing them is
private (implicitly anon-inner ones are).

There's no setAccessible() that can be done via reflection, it would
have to be an ASM solution to allow more elegant anon-inner usage.

Regards,

- Paul

On Dec 2, 2008, at 6:33 AM, Paul Hammant wrote:

> Hi Daniel,
>
> Most likely we're not going to do the most fine-grained features of
> Generics until PicoContainer 3.0 ( most of the API that refers to
> Class will be changed to refer to Type instead, and we'll do some
> capturing of potentially erased types on addComponent methods).
>
> For now though, there is a very elegant PicoContainer 2.6+ way to do
> what you want :
>
> @Test
> public void
> testCan_Use_Provider_As_Workaround_For_with_Generic_Type() {
> final DefaultPicoContainer pico = new DefaultPicoContainer();
> pico.addComponent(FictionFactory.class);
> pico.addComponent(NonFictionFactory.class);
> pico.addAdapter(new ProviderAdapter() {
> public Object getComponentKey() {
> return "bookHelperUsingFiction";
> }
> // depend on what you like in the args for the provide
> method......
> public BookHelper provide(FictionFactory fictionFactory) {
> return new BookHelper(fictionFactory);
> }
> });
> Object component = pico.getComponent("bookHelperUsingFiction");
> assertNotNull(component);
> }
>
>
> Regards,
>
> - Paul
>
> On Dec 1, 2008, at 5:43 PM, Daniel Wellman wrote:
>
>>
>> Reposting the code since the HTML formatting ate all the
>> parameterized types.
>> Doh!
>>
>>
>> public void
>> testCannot_Use_BasicComponentParameter_with_Generic_Type() {
>> DefaultPicoContainer pico = new DefaultPicoContainer();
>>
>> pico.addComponent(FictionFactory.class);
>> pico.addComponent(NonFictionFactory.class);
>>
>> // This throws a java.lang.ClassCastException:
>> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
>> pico.addComponent("bookHelperUsingFiction", BookHelper.class, new
>> BasicComponentParameter(FictionFactory.class));
>>
>> Object component = pico.getComponent("bookHelperUsingFiction");
>> assertNotNull(component);
>> }
>>
>> public static class BookHelper<T> {
>> BookFactory<T> factory;
>>
>> // The test above passes if BookFactory does not have a
>> parameterized
>> type, e.g.
>> // if it's publicBookHelper(BookFactory newFactory) { ... }
>> public BookHelper(BookFactory<T> newFactory) {
>> this.factory = newFactory;
>> }
>> }
>>
>> public static interface BookFactory<T> {
>> T build();
>> }
>>
>> public static class FictionFactory implements BookFactory<Fiction> {
>> public Fiction build() {
>> return new Fiction();
>> }
>> }
>>
>> public static class NonFictionFactory implements
>> BookFactory<NonFiction>
>> {
>>
>> public NonFiction build() {
>> return new NonFiction();
>> }
>> }
>>
>> static class Fiction {
>> }
>>
>> static class NonFiction {
>> }
>>
>> --
>> View this message in context: http://www.nabble.com/BasicComponentParameter-doesn%27t-work-with-parameterized-types-tp20784248p20784451.html
>> Sent from the NanoContainer - PicoContainer - Users mailing list
>> archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: BasicComponentParameter doesn't work with parameterized types

2008-12-02T06:33:00Z

Hi Daniel,

Most likely we're not going to do the most fine-grained features of
Generics until PicoContainer 3.0 ( most of the API that refers to
Class will be changed to refer to Type instead, and we'll do some
capturing of potentially erased types on addComponent methods).

For now though, there is a very elegant PicoContainer 2.6+ way to do
what you want :

@Test
public void
testCan_Use_Provider_As_Workaround_For_with_Generic_Type() {
final DefaultPicoContainer pico = new DefaultPicoContainer();
pico.addComponent(FictionFactory.class);
pico.addComponent(NonFictionFactory.class);
pico.addAdapter(new ProviderAdapter() {
public Object getComponentKey() {
return "bookHelperUsingFiction";
}
// depend on what you like in the args for the provide
method......
public BookHelper provide(FictionFactory fictionFactory) {
return new BookHelper(fictionFactory);
}
});
Object component = pico.getComponent("bookHelperUsingFiction");
assertNotNull(component);
}

Regards,

- Paul

On Dec 1, 2008, at 5:43 PM, Daniel Wellman wrote:

>
> Reposting the code since the HTML formatting ate all the
> parameterized types.
> Doh!
>
>
> public void
> testCannot_Use_BasicComponentParameter_with_Generic_Type() {
> DefaultPicoContainer pico = new DefaultPicoContainer();
>
> pico.addComponent(FictionFactory.class);
> pico.addComponent(NonFictionFactory.class);
>
> // This throws a java.lang.ClassCastException:
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
> pico.addComponent("bookHelperUsingFiction", BookHelper.class, new
> BasicComponentParameter(FictionFactory.class));
>
> Object component = pico.getComponent("bookHelperUsingFiction");
> assertNotNull(component);
> }
>
> public static class BookHelper<T> {
> BookFactory<T> factory;
>
> // The test above passes if BookFactory does not have a
> parameterized
> type, e.g.
> // if it's publicBookHelper(BookFactory newFactory) { ... }
> public BookHelper(BookFactory<T> newFactory) {
> this.factory = newFactory;
> }
> }
>
> public static interface BookFactory<T> {
> T build();
> }
>
> public static class FictionFactory implements BookFactory<Fiction> {
> public Fiction build() {
> return new Fiction();
> }
> }
>
> public static class NonFictionFactory implements
> BookFactory<NonFiction>
> {
>
> public NonFiction build() {
> return new NonFiction();
> }
> }
>
> static class Fiction {
> }
>
> static class NonFiction {
> }
>
> --
> View this message in context: http://www.nabble.com/BasicComponentParameter-doesn%27t-work-with-parameterized-types-tp20784248p20784451.html
> Sent from the NanoContainer - PicoContainer - Users mailing list
> archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Java configurator

2008-12-01T19:30:35Z

Hi, congrats for your project! I'm using pico to create a webapp with Derby and Glassfish embedded. I created a java configurator using annotations. My setup allows me to swap to another container. I use the factory and constructor pattern because I don't want to use @inject everywhere, the less intrusive the better.

My project is using picocontainer snaphot with maven. I want to contribute the config part if it's useful for you.

A file created in META-INF/dfxcontainer.

properties setup the container factory to use.
dfx.common.container.factory=dfx.common.container.ContainerFactoryTestImpl

META-INF/dfxconfig.properties
dfx.configs=dfx.common.config.Config1,dfx.common.config.Config2

Examples:

@DfxContainer(scope = ContainerScope1.class)
public class Config1 implements DfxConfig {

    @DfxContainerComponent(key = ComponentA.class)
    public ComponentAImpl componentA;

}

@DfxComponent(id = "core-test")
@DfxContainer(scope = ComponentScope.class)
public class CoreTestConfig implements DfxConfig {

    @DfxContainerComponent(key = dfx.core.dao.DAOFacadeMock.class)
    public dfx.core.dao.DAOFacadeMock daoFacadeMock;

    @DfxContainerComponent(key = dfx.core.plugin.IndexerPluginTest.class)
    @DfxIndexerPlugin(extensions = { "extA", "extB" }, params = {
            @DfxParam(id = "paramA", values = { "valueA" }),
            @DfxParam(id = "paramB", values = { "valueB" }) }, searchFields = {
            @DfxSearchField(value = "searchFieldA", visible = true),
            @DfxSearchField(value = "searchFieldB", visible = false) })
    public dfx.core.plugin.IndexerPluginTest indexerPluginTest;

}

Re: BasicComponentParameter doesn't work with parameterized types

2008-12-01T17:43:13Z

Reposting the code since the HTML formatting ate all the parameterized types. Doh!

public void testCannot_Use_BasicComponentParameter_with_Generic_Type() {
DefaultPicoContainer pico = new DefaultPicoContainer();

pico.addComponent(FictionFactory.class);
pico.addComponent(NonFictionFactory.class);

// This throws a java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
pico.addComponent("bookHelperUsingFiction", BookHelper.class, new BasicComponentParameter(FictionFactory.class));

Object component = pico.getComponent("bookHelperUsingFiction");
assertNotNull(component);
}

public static class BookHelper<T> {
BookFactory<T> factory;

// The test above passes if BookFactory does not have a parameterized type, e.g.
// if it's publicBookHelper(BookFactory newFactory) { ... }
public BookHelper(BookFactory<T> newFactory) {
this.factory = newFactory;
}
}

public static interface BookFactory<T> {
T build();
}

public static class FictionFactory implements BookFactory<Fiction> {
public Fiction build() {
return new Fiction();
}
}

public static class NonFictionFactory implements BookFactory<NonFiction> {

public NonFiction build() {
return new NonFiction();
}
}

static class Fiction {
}

static class NonFiction {
}

BasicComponentParameter doesn't work with parameterized types

2008-12-01T17:21:23Z

It looks like PicoContainer 2 from trunk does not allow specifying BasicComponentParameters when the target parameter has a generic/parameterized type. The following code example produces this ClassCastException:

java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
	at org.picocontainer.parameters.BasicComponentParameter.resolveInstance(BasicComponentParameter.java:161)
	at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:67)
	at org.picocontainer.injectors.SingleMemberInjector.getMemberArguments(SingleMemberInjector.java:53)
	at org.picocontainer.injectors.ConstructorInjector.getMemberArguments(ConstructorInjector.java:240)
	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:199)
	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:289)
	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:229)
	at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:573)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:537)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:514)
	at com.myexample.picocontainer.PicoAcceptanceTest.testCannot_Use_BasicComponentParameter_with_Generic_Type(PicoAcceptanceTest.java:152)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)

Here's the example:

   public void testCannot_Use_BasicComponentParameter_with_Generic_Type() {
      DefaultPicoContainer pico = new DefaultPicoContainer();

      pico.addComponent(FictionFactory.class);
      pico.addComponent(NonFictionFactory.class);
      pico.addComponent("bookHelperUsingFiction", BookHelper.class, new BasicComponentParameter(FictionFactory.class));

      // This throws a java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
      Object component = pico.getComponent("bookHelperUsingFiction");
      assertNotNull(component);
   }

   public static class BookHelper {
      BookFactory factory;

      // The test above passes if BookFactory does not have a parameterized type, e.g.
      // if it's publicBookHelper(BookFactory newFactory) { ... }
      public BookHelper(BookFactory newFactory) {
         this.factory = newFactory;
      }
   }

   public static interface BookFactory {
      T build();
   }

   public static class FictionFactory implements BookFactory {
      public Fiction build() {
         return new Fiction();
      }
   }

   public static class NonFictionFactory implements BookFactory {

      public NonFiction build() {
         return new NonFiction();
      }
   }

   static class Fiction {
   }

   static class NonFiction {
   }

Re: Problem with annotation injection in abstract classes

2008-11-30T17:04:38Z

Yeah, I can repro and have fixed. It was to do with AdaptingInjection which has duplicate code for sniffing for the @Inject annotation.

- Paul

On Nov 30, 2008, at 4:43 AM, Jonathan Ariel wrote:

You are right... it is working, the problem appears when you use withAutomatic() instead of withAnnotatedFieldInjection().
In my case I need both annotation and constructor injection. Do you think that it should work when using withAutomatic?

On Sat, Nov 29, 2008 at 12:01 PM, Paul Hammant <paul@...> wrote:

Jonathan.

I can't reproduce :-(

Is the following representative ...............

   public static abstract class A2 {
   @Inject

   protected D2 d2;
   }

   public static abstract class B2 extends A2 {
   }

   public static class C2 extends B2 {
   }

   public static class D2 {
   }

   @Test
   public void testThatEvenMoreSuperClassCanHaveAnnotatedFields() {
   MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
   container.addComponent(D2.class);
   container.addComponent(C2.class);

   C2 c2 = container.getComponent(C2.class);
   assertNotNull(c2);
   assertNotNull(c2.d2);
   }

Regards,

- Paul

On Nov 27, 2008, at 3:06 PM, Jonathan Ariel wrote:

I seems to still have problems with this... and it is when I have more than one level of inheritance... for example:

C extends B that extends A

B and A are abstract

in A I'm injecting D

when getting an instance of C from the container, D is null.

On Wed, Nov 26, 2008 at 1:24 PM, Jonathan Ariel <ionathan@...> wrote:

I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: Problem with annotation injection in abstract classes

2008-11-29T23:48:32Z

Should do. I'll look into it.

Regards,

- Paul

On Nov 30, 2008, at 4:43 AM, Jonathan Ariel wrote:

You are right... it is working, the problem appears when you use withAutomatic() instead of withAnnotatedFieldInjection().
In my case I need both annotation and constructor injection. Do you think that it should work when using withAutomatic?

On Sat, Nov 29, 2008 at 12:01 PM, Paul Hammant <paul@...> wrote:

Jonathan.

I can't reproduce :-(

Is the following representative ...............

   public static abstract class A2 {
   @Inject

   protected D2 d2;
   }

   public static abstract class B2 extends A2 {
   }

   public static class C2 extends B2 {
   }

   public static class D2 {
   }

   @Test
   public void testThatEvenMoreSuperClassCanHaveAnnotatedFields() {
   MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
   container.addComponent(D2.class);
   container.addComponent(C2.class);

   C2 c2 = container.getComponent(C2.class);
   assertNotNull(c2);
   assertNotNull(c2.d2);
   }

Regards,

- Paul

On Nov 27, 2008, at 3:06 PM, Jonathan Ariel wrote:

I seems to still have problems with this... and it is when I have more than one level of inheritance... for example:

C extends B that extends A

B and A are abstract

in A I'm injecting D

when getting an instance of C from the container, D is null.

On Wed, Nov 26, 2008 at 1:24 PM, Jonathan Ariel <ionathan@...> wrote:

I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: Problem with annotation injection in abstract classes

2008-11-29T20:43:45Z

You are right... it is working, the problem appears when you use withAutomatic() instead of withAnnotatedFieldInjection().
In my case I need both annotation and constructor injection. Do you think that it should work when using withAutomatic?

On Sat, Nov 29, 2008 at 12:01 PM, Paul Hammant <paul@...> wrote:

Jonathan.

I can't reproduce :-(

Is the following representative ...............

   public static abstract class A2 {
   @Inject

   protected D2 d2;
   }

   public static abstract class B2 extends A2 {
   }

   public static class C2 extends B2 {
   }

   public static class D2 {
   }

   @Test
   public void testThatEvenMoreSuperClassCanHaveAnnotatedFields() {
   MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
   container.addComponent(D2.class);
   container.addComponent(C2.class);

   C2 c2 = container.getComponent(C2.class);
   assertNotNull(c2);
   assertNotNull(c2.d2);
   }

Regards,

- Paul

On Nov 27, 2008, at 3:06 PM, Jonathan Ariel wrote:

I seems to still have problems with this... and it is when I have more than one level of inheritance... for example:

C extends B that extends A

B and A are abstract

in A I'm injecting D

when getting an instance of C from the container, D is null.

On Wed, Nov 26, 2008 at 1:24 PM, Jonathan Ariel <ionathan@...> wrote:

I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: CollectionComponentParameter works differently with generic Collection types?

2008-11-29T06:01:45Z

Fixed I think. Jar by separate email.

Regards,

- Paul

On Nov 27, 2008, at 2:29 PM, Daniel Wellman wrote:

Paul,

Thanks for taking a look at this!

Cheers,
Dan

On Thu, Nov 27, 2008 at 7:00 AM, Paul Hammant <paul@...> wrote:

Well I can reproduce this easily enough. I'm playing with alternatives for fixing it Daniel...

Regards,

- Paul

On Nov 25, 2008, at 1:05 AM, Daniel Wellman wrote:

Has the behavior of CollectionComponentParameter changed now that Pico 2
recognizes generic collection parameter types?

In the example below, I expected that adding a CollectionComponentParameter
with a componentValueType of Cod.class would only have Cod fish in the bowl,
but I observe that it gets both Cod and Shark.

If I repeat the experiment by making the Bowl have a type-erased List, the
test works as I expect -- I only get a Cod.

Is this the expected behavior for typed collections?

Test below:

public void testRegisteringSubsetOfGenericCollectionParameters() {
DefaultPicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Cod.class);
pico.addComponent(Shark.class);
pico.addComponent(GenericBowl.class, GenericBowl.class,
new CollectionComponentParameter(Cod.class, false));

GenericBowl bowl = pico.getComponent(GenericBowl.class);
// FAILS with PicoContainer 2.7-SNAPSHOT, returns 2
assertEquals(1, bowl.fishes.size());
}

// Types

public static interface Fish {
}

public static class Cod implements Fish {
}

public static class Shark implements Fish {
}

public static class GenericBowl {
List<Fish> fishes;

public GenericBowl(List<Fish> fishes) {
this.fishes = fishes;
}
}

... but this one passes:

public void testRegisteringSubsetOfTypeErasedCollectionParameters() {
DefaultPicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Cod.class);
pico.addComponent(Shark.class);
pico.addComponent(GenericBowl.class, GenericBowl.class,
new CollectionComponentParameter(Fish.class, false));

GenericBowl bowl = pico.getComponent(GenericBowl.class);
assertEquals(2, bowl.fishes.size());
assertTrue(CollectionUtilities.contains(bowl.fishes, new
ContainsInstanceOfTypePredicate(Cod.class)));
assertTrue(CollectionUtilities.contains(bowl.fishes, new
ContainsInstanceOfTypePredicate(Shark.class)));
}

public static class TypeErasedListBowl {
List fishes;

public TypeErasedListBowl(List fishes) {
this.fishes = fishes;
}
}

--
View this message in context: http://www.nabble.com/CollectionComponentParameter-works-differently-with-generic-Collection-types--tp20673363p20673363.html
Sent from the NanoContainer - PicoContainer - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Problem with annotation injection in abstract classes

2008-11-29T06:01:42Z

Jonathan.

I can't reproduce :-(

Is the following representative ...............

public static abstract class A2 {

@Inject

protected D2 d2;

}

public static abstract class B2 extends A2 {

}

public static class C2 extends B2 {

}

public static class D2 {

}

@Test

public void testThatEvenMoreSuperClassCanHaveAnnotatedFields() {

MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();

container.addComponent(D2.class);

container.addComponent(C2.class);

C2 c2 = container.getComponent(C2.class);

assertNotNull(c2);

assertNotNull(c2.d2);

}

Regards,

- Paul

On Nov 27, 2008, at 3:06 PM, Jonathan Ariel wrote:

I seems to still have problems with this... and it is when I have more than one level of inheritance... for example:

C extends B that extends A

B and A are abstract

in A I'm injecting D

when getting an instance of C from the container, D is null.

On Wed, Nov 26, 2008 at 1:24 PM, Jonathan Ariel <ionathan@...> wrote:
I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: Problem with annotation injection in abstract classes

2008-11-27T07:06:42Z

I seems to still have problems with this... and it is when I have more than one level of inheritance... for example:

C extends B that extends A

B and A are abstract

in A I'm injecting D

when getting an instance of C from the container, D is null.

On Wed, Nov 26, 2008 at 1:24 PM, Jonathan Ariel <ionathan@...> wrote:

I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: CollectionComponentParameter works differently with generic Collection types?

2008-11-27T06:29:18Z

Paul,

Thanks for taking a look at this!

Cheers,

Dan

On Thu, Nov 27, 2008 at 7:00 AM, Paul Hammant <paul@...> wrote:

Well I can reproduce this easily enough. I'm playing with alternatives for fixing it Daniel...

Regards,

- Paul

On Nov 25, 2008, at 1:05 AM, Daniel Wellman wrote:

Has the behavior of CollectionComponentParameter changed now that Pico 2
recognizes generic collection parameter types?

In the example below, I expected that adding a CollectionComponentParameter
with a componentValueType of Cod.class would only have Cod fish in the bowl,
but I observe that it gets both Cod and Shark.

If I repeat the experiment by making the Bowl have a type-erased List, the
test works as I expect -- I only get a Cod.

Is this the expected behavior for typed collections?

Test below:

public void testRegisteringSubsetOfGenericCollectionParameters() {
DefaultPicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Cod.class);
pico.addComponent(Shark.class);
pico.addComponent(GenericBowl.class, GenericBowl.class,
new CollectionComponentParameter(Cod.class, false));

GenericBowl bowl = pico.getComponent(GenericBowl.class);
// FAILS with PicoContainer 2.7-SNAPSHOT, returns 2
assertEquals(1, bowl.fishes.size());
}

// Types

public static interface Fish {
}

public static class Cod implements Fish {
}

public static class Shark implements Fish {
}

public static class GenericBowl {
List<Fish> fishes;

public GenericBowl(List<Fish> fishes) {
this.fishes = fishes;
}
}

... but this one passes:

public void testRegisteringSubsetOfTypeErasedCollectionParameters() {
DefaultPicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Cod.class);
pico.addComponent(Shark.class);
pico.addComponent(GenericBowl.class, GenericBowl.class,
new CollectionComponentParameter(Fish.class, false));

GenericBowl bowl = pico.getComponent(GenericBowl.class);
assertEquals(2, bowl.fishes.size());
assertTrue(CollectionUtilities.contains(bowl.fishes, new
ContainsInstanceOfTypePredicate(Cod.class)));
assertTrue(CollectionUtilities.contains(bowl.fishes, new
ContainsInstanceOfTypePredicate(Shark.class)));
}

public static class TypeErasedListBowl {
List fishes;

public TypeErasedListBowl(List fishes) {
this.fishes = fishes;
}
}

--
View this message in context: http://www.nabble.com/CollectionComponentParameter-works-differently-with-generic-Collection-types--tp20673363p20673363.html
Sent from the NanoContainer - PicoContainer - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: CollectionComponentParameter works differently with generic Collection types?

2008-11-27T04:00:55Z

Well I can reproduce this easily enough. I'm playing with
alternatives for fixing it Daniel...

Regards,

- Paul

On Nov 25, 2008, at 1:05 AM, Daniel Wellman wrote:

>
> Has the behavior of CollectionComponentParameter changed now that
> Pico 2
> recognizes generic collection parameter types?
>
> In the example below, I expected that adding a
> CollectionComponentParameter
> with a componentValueType of Cod.class would only have Cod fish in
> the bowl,
> but I observe that it gets both Cod and Shark.
>
> If I repeat the experiment by making the Bowl have a type-erased
> List, the
> test works as I expect -- I only get a Cod.
>
> Is this the expected behavior for typed collections?
>
> Test below:
>
>
> public void testRegisteringSubsetOfGenericCollectionParameters() {
> DefaultPicoContainer pico = new DefaultPicoContainer();
> pico.addComponent(Cod.class);
> pico.addComponent(Shark.class);
> pico.addComponent(GenericBowl.class, GenericBowl.class,
> new CollectionComponentParameter(Cod.class, false));
>
>
> GenericBowl bowl = pico.getComponent(GenericBowl.class);
> // FAILS with PicoContainer 2.7-SNAPSHOT, returns 2
> assertEquals(1, bowl.fishes.size());
> }
>
> // Types
>
> public static interface Fish {
> }
>
> public static class Cod implements Fish {
> }
>
> public static class Shark implements Fish {
> }
>
> public static class GenericBowl {
> List<Fish> fishes;
>
> public GenericBowl(List<Fish> fishes) {
> this.fishes = fishes;
> }
> }
>
>
>
> ... but this one passes:
>
>
>
> public void
> testRegisteringSubsetOfTypeErasedCollectionParameters() {
> DefaultPicoContainer pico = new DefaultPicoContainer();
> pico.addComponent(Cod.class);
> pico.addComponent(Shark.class);
> pico.addComponent(GenericBowl.class, GenericBowl.class,
> new CollectionComponentParameter(Fish.class, false));
>
>
> GenericBowl bowl = pico.getComponent(GenericBowl.class);
> assertEquals(2, bowl.fishes.size());
> assertTrue(CollectionUtilities.contains(bowl.fishes, new
> ContainsInstanceOfTypePredicate(Cod.class)));
> assertTrue(CollectionUtilities.contains(bowl.fishes, new
> ContainsInstanceOfTypePredicate(Shark.class)));
> }
>
>
> public static class TypeErasedListBowl {
> List fishes;
>
> public TypeErasedListBowl(List fishes) {
> this.fishes = fishes;
> }
> }
>
>
> --
> View this message in context: http://www.nabble.com/CollectionComponentParameter-works-differently-with-generic-Collection-types--tp20673363p20673363.html
> Sent from the NanoContainer - PicoContainer - Users mailing list
> archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Problem with annotation injection in abstract classes

2008-11-26T07:24:11Z

I agree. I'll change my code. Thanks! Good reasons :)

On Wed, Nov 26, 2008 at 11:46 AM, Daniel Wellman <etldan@...> wrote:

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: Problem with annotation injection in abstract classes

2008-11-26T05:46:36Z

On Wed, Nov 26, 2008 at 2:50 AM, Paul Hammant <paul@...> wrote:

Well five is a bit borderline, yes. Firstly, if you're using IDEA for looking after your component set, then using the refactoring "introduce parameter" can help lots - it you do that in the super class, all subclasses will get it too. Then there's "Change method signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are dependencies and wonder if there is some separation of concerts. They would try to look to see if there is some intermediate dependency that could encompass the capabilities of, say, three of the components. With the introduction of the intermediate component, you would see a reduce number of deps going into the final one. Of course, that's easy for me to say not having seen your set of components.

I agree; I like Constructor Injection for a few reasons:

You know you always have all your dependencies when you get an instance of your component from the container. You don't have to write any "afterInitialized" method where you check that you really have all your dependencies set -- Spring does this, I don't know about Guice. For testing it's particularly nice because you know all your required dependencies by looking at the constructor. With setter injection, it's up to the programmer to look at all the bean properties and make sure they're all set in the test.

Constructor injection is even more compelling when you are adding new dependencies to existing classes -- the IDE will remind you that your test objects are missing dependencies (because they are missing a constructor parameter) whereas setter injection will probably cause the test to fail at runtime with a NullPointerException.

Re: Too many dependencies

As Paul said, if you have too many dependencies, there's probably some other abstraction which is trying to come out. Just like testing with mock objects can tell you if your interfaces need rethinking ("Why do I have to mock all these calls to get my code to work?"), long constructor lists can tell if you if you have too many or unusual dependencies.

And yes, a good IDE will help you deal with the mechanics of introducing new parameters, moving them, etc.

Dan

Re: Problem with annotation injection in abstract classes

2008-11-25T23:50:42Z

Jonathan,

On Nov 26, 2008, at 12:23 AM, Jonathan Ariel wrote:

> Thank you very much! Really great job!
> I understand that using constructor injection is better, but I don't
> like it when I have lots of dependencies (I mean 4 or 5 or even
> more). because that mean lots of parameters on every constructor of
> every subclass. If I discover that I need a new parameter in the
> super class constructor, I'll have to go and change every subclass
> constructor.
> Do you think there is a better way to do that?

Well five is a bit borderline, yes. Firstly, if you're using IDEA for
looking after your component set, then using the refactoring
"introduce parameter" can help lots - it you do that in the super
class, all subclasses will get it too. Then there's "Change method
signature" which IDEA and Eclipse have.

Alternatively, the purists may study the five components that are
dependencies and wonder if there is some separation of concerts. They
would try to look to see if there is some intermediate dependency that
could encompass the capabilities of, say, three of the components.
With the introduction of the intermediate component, you would see a
reduce number of deps going into the final one. Of course, that's
easy for me to say not having seen your set of components.

Are you using our @Inject annotation, or using your own one? You'd be
using your own one if you're aiming at having the least dependency on
PicoContainer's classbase.

>
> BTW really good job with PicoContainer. Good documentation also!

Thanks. We've been improving it over the last year or so :-)

Regards,

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Problem with annotation injection in abstract classes

2008-11-25T16:23:53Z

Thank you very much! Really great job!
I understand that using constructor injection is better, but I don't like it when I have lots of dependencies (I mean 4 or 5 or even more). because that mean lots of parameters on every constructor of every subclass. If I discover that I need a new parameter in the super class constructor, I'll have to go and change every subclass constructor.
Do you think there is a better way to do that?

BTW really good job with PicoContainer. Good documentation also!

On Tue, Nov 25, 2008 at 10:14 PM, Paul Hammant <paul@...> wrote:

Jonathan,

Fixed in revision 5083 for PicoContainer 2.7, thanks for reporting this.

If you can, you should really use Constructor Injection. Even the Guice team recommends this :-)

I've emailed you a snapshot jar separately.

Regards,

- Paul

On Nov 25, 2008, at 7:57 PM, Jonathan Ariel wrote:

Hi! I'm trying to do something like this without good results. Am I doing something wrong?

public abstract class A {
@Inject
protected C c;

}

public class B extends A {
}

public class C {
}

MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
container.addComponent(C.class);
container.addComponent(B.class);

and finally in when I do:

B b = container.getComponent(B.class);

in b the field c is null. I think the expected behavior is c being injected with an instance of C.

What do you think?

Thanks,

Jonathan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: CollectionComponentParameter works differently with generic Collection types?

2008-11-25T16:15:56Z

It could be Daniel. Ill compare your case for PicoContainer 2.4 and
latest to observe (and fix?) the difference.

Regards,

- Paul

On Nov 25, 2008, at 1:05 AM, Daniel Wellman wrote:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Problem with annotation injection in abstract classes

2008-11-25T16:14:35Z

Jonathan,

Fixed in revision 5083 for PicoContainer 2.7, thanks for reporting this.

If you can, you should really use Constructor Injection. Even the
Guice team recommends this :-)

I've emailed you a snapshot jar separately.

Regards,

- Paul

On Nov 25, 2008, at 7:57 PM, Jonathan Ariel wrote:

> Hi! I'm trying to do something like this without good results. Am I
> doing something wrong?
>
> public abstract class A {
> @Inject
> protected C c;
>
> }
>
> public class B extends A {
> }
>
> public class C {
> }
>
>
>
> MutablePicoContainer container = new
> PicoBuilder().withAnnotatedFieldInjection().build();
> container.addComponent(C.class);
> container.addComponent(B.class);
>
> and finally in when I do:
>
> B b = container.getComponent(B.class);
>
> in b the field c is null. I think the expected behavior is c being
> injected with an instance of C.
>
> What do you think?
>
> Thanks,
>
> Jonathan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

RE: Problem with annotation injection in abstract classes

2008-11-25T13:36:00Z

IMO, Guice 2 does a much better job with the injection... Pico is not very injection friendly...
Pico doesn't currently handle inheritance with the injection. I asked for that feature long ago...

Erik.

________________________________________
From: Jonathan Ariel [mailto:ionathan@...]
Sent: November 25, 2008 2:58 PM
To: user@...
Subject: [picocontainer-user] Problem with annotation injection in abstract classes

Hi! I'm trying to do something like this without good results. Am I doing something wrong?

public abstract class A {
@Inject
protected C c;

}

public class B extends A {
}

public class C {
}

MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
container.addComponent(C.class);
container.addComponent(B.class);

and finally in when I do:

B b = container.getComponent(B.class);

in b the field c is null. I think the expected behavior is c being injected with an instance of C.

What do you think?

Thanks,

Jonathan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Problem with annotation injection in abstract classes

2008-11-25T11:57:36Z

Hi! I'm trying to do something like this without good results. Am I doing something wrong?

public abstract class A {
@Inject
protected C c;

}

public class B extends A {
}

public class C {
}

MutablePicoContainer container = new PicoBuilder().withAnnotatedFieldInjection().build();
container.addComponent(C.class);
container.addComponent(B.class);

and finally in when I do:

B b = container.getComponent(B.class);

in b the field c is null. I think the expected behavior is c being injected with an instance of C.

What do you think?

Thanks,

Jonathan