Todor Boev wrote:
Richard S. Hall wrote:
Yes, this is an open-ended question and there is likely no single
answer.
The mission of iPOJO is to make creating dynamic applications
simpler. Precisely how you use it to accomplish this depends on your
use case.
The main debate, it seems, is when to use an object and when to use a
component. Since iPOJO components handle dynamism (among other
things), you may choose to use it for those pieces of your
application that require dynamism, for example, but it is difficult
to say when to decide between object vs component. Granularity is
another metric.
iPOJO is a full-blown, hierarchical component model built on top of
an object-oriented language. In the end, it leaves these decisions up
to you.
-> richard
Does this mean iPojo strives to make it easy for me to smoothly evolve
my bundle through the entire continuum starting from
one-uber-component and ending at all-is-component? Naturally I am free
to stop at any appropriate point during this evolution.
I wouldn't say that iPOJO strives to make that easy for you, but it
should support the approach that you choose. iPOJO strives to make
highly dynamic applications as easy to create as non-dynamic
applications. Of course, static applications are a subset of dynamic
applications, so it can still make your life easier (e.g., dependency
injection, configuration injection, etc) in that case too.
Originally, the focus of iPOJO was to simplify OSGi application
development and create a component model that enabled seamless,
transparent integration with OSGi's dynamic service model. It was not
really a goal to have iPOJO also define how you created your inner
objects and/or smaller-grained components. However, over time it has
moved into this direction and will probably continue to do so. Clement
and I were recently talking about more features on the roadmap that move
iPOJO further in this direction. So the answer to this question is evolving.
On the practical side:
1) Is it possible (and ideally easy and clean) for components to
create, configure and manage the lifecycle of other components at
runtime? This is required for all stages where near the
all-is-component point as I replace more and more of the traditional
object construction with the higher-abstraction of component instance
construction. Still not all components need to exist all the time - in
fact only a small set of "core" components do. For example in the
classical runtime scope hierarchy of application-session-request only
the application scoped components exist all the time while the session
and request scoped components must be created and destroyed depending
on the number and state of sessions.
As Clement mentioned, you can manage component lifecycle through iPOJO
component factory services, not to be confused with OSGi service
factories. I think composite components might also be interesting to you
here, since you can create a composite component that is really a
composition of smaller components. The resulting composite is just like
any normal component, meaning you can create instance of it and iPOJO
will manage it according to the needs of its internal composition.
2) If a component propagates a service dependency to objects that are
created in the traditional way will iPojo support that dependency
within these objects?. For example consider the case when a component
has a temporal dependency. That component creates a new object and
passes the dependency to it. Later some code within this new object
calls the dependency. Will iPojo perform all the required management
of this call: block for the required period and when it expires throw
an exception or delegate to a default implementation? Things like
these are again required for all the "mixed" stages where the
create-configure-start-stop-destroy state machine of some objects is
managed by iPojo and of other objects by the programmer.
iPOJO does not proxy services to avoid the performance penalty. So, if
you pass a reference to a service you are passing an unmanaged object.
Although it is not necessarily optimal, as Clement points out you can
fairly easily create your own kinds of proxies in iPOJO (typically with
temporal dependencies) to address this situation. Of course, if you have
a suggestion for ways to improve this approach, please file a RFE in
JIRA for iPOJO.
Thanks for the interesting questions.
-> richard
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
