Hi, There are three main ways to deal with your issue:
1) defining your own ‘factory’ service that will get you the instance when required 2) providing a custom creation policy (http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html#service-serving-object-creation) (you modify when objects are created) 3) creating component instances on demand, and retrieving a exposed service by the newly created instance. The first approach requires changing your business code to create the objects when you want. The second approach is more transparent, but bound your code to iPOJO. With the third way, you can use the ‘instance.name’ property to identify your service (see http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.html#accessing-services-exposed-by-created-instances). Regards, Clement On 7 août 2014 at 21:40:52, alejandro.e...@grassvalley.com (alejandro.e...@grassvalley.com) wrote: So the next question is whose job is it to create these instances (I mean in general terms, best practice, I know the complete answer probably is "it depends on the application"). What I end up usually doing is that the consumer (the one with the @Requires Foo) ends up having ALSO (one more dependency) a @Requires Factory with a filter to get a Foo-factory and then when i need to use Foo for the first time I have to do a super ugly Dictionary<String, Object> arguments = new Hashtable<>(); //One more dependency to Dictionary, one more dependency to Hashtable myFoo = (Foo) ((InstanceManager) fooFactory.createComponentInstance( arguments)).getPojoObject(); //two casts in one line! But this is a pain to manage because now consumers become coupled to iPojo factories (or Instance if using @Configuration) and what's worse is that the factories are usually the ones for a concrete implementation of the interface, which again increases coupling and destroys implementation substitutability. This is why I would expect iPojo to create instances implicitly, so that nobody has to be coupled to internal iPojo structures to create instances (after all, the library is called i POJO, but all these requirements make the consumer not a POJO anymore, at least in my view) The only case I see where you don't couple the consumer to iPojo is when the provider is a singleton (@Instantiate); if not, the consumer or some other 3rd party class will be coupled to Factory, InstanceManager, ConfigurationException, MIssingHandlerException, UnnaceptableConfiguration (when using the Factories technique that is). I don't see XML as a viable instantiation option in my case, I want to control everything with annotations and in source code files. Finally, I have to say that I am fairly certain I am doing things the wrong way and that there must be a clean, low-coupling way to handle instance creation that I don't know yet. Is there any sample code of a real system? not dummy samples that always use @Instantiate? Thank you for your help Clement Alejandro Endo | Software Designer/Concepteur de logiciels From: Clement Escoffier <clement.escoff...@gmail.com> To: <users@felix.apache.org>, Date: 2014-08-07 02:44 AM Subject: Re: iPojo explicit instantiation mechanism Hi, I understand the confusion, because the current wording used there is kind of misleading. @Component actually defines a component factory, use to create component instance (container and content). But it does not create an instance of it. To create an instance, use @Instantiate, or one of the different mechanism for this (factory service, configuration admin, instance declaration, API?). By default, the instance contains only one ?business? object (an instance of the implementation class). The @Provides Instance strategy let you change this behavior: - ?factory?: creates one business objects by requesting bundle (it?s the service factory OSGi policy) - ?instance? : creates one business objects by requesting iPOJO instance So the ?instance? policy acts on the business object creation not on the component instance creation. iPOJO does not try to create component instances directly because it may require advanced configuration that it can?t deduce. Clement On 7 août 2014 at 00:15:36, alejandro.e...@grassvalley.com (alejandro.e...@grassvalley.com) wrote: Hello, I would like to understand something about @components and instances. If I have a service @Component Foo with a strategy of INSTANCE and I have a @Component consumer Bar with a field @Requires Foo, why is the instance not created automatically by iPojo? there is a valid factory for Foo ready to create instances and there is an invalid Bar waiting for an instance of Foo, why doesn't iPojo instantiate Foo due to the demand for it? i know about the other techniques to instantiate, that's not my question. In other words, why doesn't iPojo handle instance creation internally/implicitly (at least in such trivial cases as a factory being valid and a consumer being invalid due to a missing instance of the valid factory), why is it the job of the developer to use a factory or a @Configuration annotation or xml explicitly? Thank you Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
