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.

Reply via email to