2008/10/30 Todor Boev <[EMAIL PROTECTED]>
> 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.
>
> 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.
Yes, it is possible. By using the iPOJO factory principles, you can create,
(re)configure, start, stop and dispose instances. Factories are accessible
trough the OSGi registry, and so those operations are accessible from your
code.
>
>
> 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.
That is not directly possible. However, you can do this as following:
public class ConsumerImpl {
// Temporal dependency on FooService
FooService fs;
// An helper object
ConsumerHelper helper;
public ConsumerImpl() {
helper = new ConsumerHelper(new FooService() {
public void doSomething() {
System.out.println("Delegate on fs");
// Use the temporal dependency
fs.doSomething();
}
});
}
}
So, you create a kind of smart proxy delegating on the temporal dependency
(on regular dependency). By doing this:
- The helper object inherits of the dependency behavior
(default-implementation, nullable ...)
- You can control the delegation policy
Regards,
Clement
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
