2

We have found code like

private String string = "Not injected.";

@Inject
public void setString(@Named("s") String s) {
    this.string = s;
}

(utilitzing JSR-330 annotations) to be very useful to pass in a string value for "s". We would like to be as flexible as possible regarding which container to use, hence also Picocontainer.

As written, Picocontainer silently ignores the inject. How would I hint to PicoContainer to inject e.g. "String injected!" here?

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347

1 Answers1

0

Stable pico 2.x does not have full support for JSR-330 (your particular case), pico 3.x will have. Anyway, @named is not a good way to use picocontainer powers and not a good design for IoC centered app at all. Probably you don't need pico, if you use this stuff.

xeye
  • 1,250
  • 10
  • 15
  • Thank you for your answer. I will reevaluate pico when 3.x ships. I would appreciate learning why exactly this "inject configuration string" approach (which is valid JSR-330 and works in Spring, Guice and Weld) is not a good design, if you care to elaborate. – Thorbjørn Ravn Andersen Jan 25 '13 at 07:23
  • Major reason to love IoC containers is the way how they reduce dependencies in our code or at least put them in the single place to control. Obviously hinting the container to inject "right" instance in particular place is violating both "dep. reduction" and "keeping dep. configuration in one place". It's just a legacy habit like using "goto" when one is not aware of a better solution. – xeye Jan 25 '13 at 07:38
  • Then we agree. We use this for configuration strings, and keep the actual values in a central location. The whole _idea_ of dependency injection is to hint the container to inject what you need at a particular location, so I think this is actually a very _good_ example of proper usage of dependency injection. – Thorbjørn Ravn Andersen Jan 25 '13 at 08:28
  • That's the arguable point :) And you need to dip into pico to get clear understanding of the other side. Good container configuration just does not need any hinting. The type to inject should be unique in the container scope (and scopes can make hierachical tree to compose flexible "namespaces" if needed) or injection target can automatically get several instances of a type from the container as a collection. – xeye Jan 25 '13 at 21:59
  • We have a need to inject configuration strings into our code. The string type is final, so no subclassing is possible. Feel free to tell me how a suitable mechanism for defining that given two injection points, A and B, that A should have an "a" injected and B a "b". – Thorbjørn Ravn Andersen Jan 25 '13 at 23:04
  • Single configuration primitive is just a wrong thing to inject and the ambiguity makes it even worse. Better approach is to inject a Map|Properties filled with configuration items or a Bean or a Configuration service for the difficult cases. Single configuration is not a dependency, Spring just created a bad practice about it. – xeye Jan 26 '13 at 18:54
  • _Calling_ things wrong, does not _make_ them wrong. Our approach makes it a fatal error with Guice at the time the injector is constructed if a configuration string is missing - your approach delegates the error detection to my code instead of the container. I do not think you are right in believing that your approach is undoubtedly better than mine. Also, it is supported by all other containers claiming JSR-330 compliancy except Pico. – Thorbjørn Ravn Andersen Jan 26 '13 at 20:49