You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/18 18:17:04 UTC
Definition of IoC (was Re: [proposal] IoC type 3.14 extension to
the Avalon Framework)
Ulrich Mayring wrote:
> Niclas Hedhman wrote:
>
>>
>> ?? Since when can you control the lifecycle ??
>> I must have missed that feature/bug ;o)
>
>
> It's called IOC :-)
>
> In Avalon you can control a component's lifecycle, in type3 you can't,
> because the component decides itself. No way of knowing what it does in
> its constructor. So I actually wonder whether type3 is IOC at all.
>
It is sometimes difficult to separate out what exactly IoC looks like when
there are so many ways to implement it. That is why it is a *pattern* and
not a predefined library.
At its root, IoC means inversion of control. The component does not decide
what facilities it uses, that information is provided to the component by
the container. Whether this is done through a constructor, getter/setter,
or an interface (like Avalon 4), is irrelevant. As long as the life of the
component is directly controlled by the container, and not by itself then we
have IOC.
There are three basic "Phases" of life for a component: construction, active
use, and destruction.
What the "Type 3" IoC approach does is collapse all of the construction phase
into the constructor. That is the contract between the component and the
container.
The "Type 2" IoC approach is not to use interfaces beyond the simple
Initializable and Desposable style interfaces. Any method calls before
the initialize() method is called are construction phase calls. Essentially
it looks like a JavaBean with setters/getters for all configuration points
and external service provision. This is roughly what javax.sql.DataSource
components do.
The "Type 1" IoC approach is Avalon 4.
The titles of "Type 1,2,3,XXX" were applied by the folks who created nano and
pico container.
The choice of how to apply IoC is a matter of taste in many cases. If
everything is passed in the constructor, then we have a more atomic construction
phase. But in reality no component is used until after the construction phase.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Some people here would say, the component writer already knows which order
> things must be executed, and if that is violated (by mistake for instance),
> the unit testing would catch it.
You're right, but the violator wouldn't write unit tests for that :)
If there were some generic unit tests usable "out of the box", that
would be quite different.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension to the Avalon Framework)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 19 November 2003 17:02, Ulrich Mayring wrote:
> Niclas Hedhman wrote:
> > Guys, remember Ulrich doesn't do UnitTesting at all, so he need the
> > container to enforce the accuracy of his code. He assumes that the
> > component writer is an idiot, who doesn't know how to code and need all
> > the UnitTesting to happen in runtime ;o)
>
> The container is responsible for calling the lifecycle methods in the
> correct order. Don't know what that has to do with unit testing. It has
> a lot to do with coding conventions in a multi-developer team. Maybe you
> guys work on your components all by yourself, but we have 9 people using
> each other's components, so standards are very important.
I was implying that you want an external party to enforce the component
developer to "configure before starting threads", and all the other execution
requirements of the component.
Some people here would say, the component writer already knows which order
things must be executed, and if that is violated (by mistake for instance),
the unit testing would catch it.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Guys, remember Ulrich doesn't do UnitTesting at all, so he need the container
> to enforce the accuracy of his code. He assumes that the component writer is
> an idiot, who doesn't know how to code and need all the UnitTesting to happen
> in runtime ;o)
The container is responsible for calling the lifecycle methods in the
correct order. Don't know what that has to do with unit testing. It has
a lot to do with coding conventions in a multi-developer team. Maybe you
guys work on your components all by yourself, but we have 9 people using
each other's components, so standards are very important.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension to the Avalon Framework)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 19 November 2003 02:32, Leo Simons wrote:
> Ulrich Mayring wrote:
> > Berin Loritsch wrote:
> >> The choice of how to apply IoC is a matter of taste in many cases. If
> >> everything is passed in the constructor, then we have a more atomic
> >> construction phase. But in reality no component is used until after the
> >> construction phase.
> >
> > Yep, but you have no control over the order in which the lifecycles
> > Compose, Configure, Initialize, Contextualize etc. are called.
>
> depending on how you look at it...you have control using 'type 3', and
> you don't have control (its dictated by the framework semantics) using
> avalon-framework.
Guys, remember Ulrich doesn't do UnitTesting at all, so he need the container
to enforce the accuracy of his code. He assumes that the component writer is
an idiot, who doesn't know how to code and need all the UnitTesting to happen
in runtime ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Stephen McConnell <mc...@apache.org>.
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>
>>
>> The choice of how to apply IoC is a matter of taste in many cases. If
>> everything is passed in the constructor, then we have a more atomic
>> construction
>> phase. But in reality no component is used until after the
>> construction phase.
>
>
> Yep, but you have no control over the order in which the lifecycles
> Compose, Configure, Initialize, Contextualize etc. are called.
> Everything is collapsed within the constructor and it is assumed that
> the order of construction is irrelevant.
>
> However, it does make a difference whether you initialize an
> unconfigured component or configure an uninitialized component. For
> example, a component that accesses an external resource might need a
> username/password before it can do that. So it is vital that this
> component passes through configuration before initialisation.
>
> Of course it is possible to maintain the correct order in a
> constructor, but it cannot be guaranteed anymore. The component itself
> decides.
Actually isn't it the containers job to ensure that everything supplied
atomically (i.e. via the constructor) are consitent? No ordering should
be assumed in the atomic case.
Stephen.
>
>
> Ulrich
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
>> Ulrich Mayring wrote:
>>> Leo Simons wrote:
>>>
>>>> class MyComponent implements Configurable
>>>> {
>>>> public void configure( Configuration config )
>>>> {
>>>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>>>> // possible
>>>> m_val = config.getChild("blah").value();
>>>> }
>>>> }
>>>
>>> We have invented an application framework on top of Avalon to prevent
>>> things like that.
<snip/>
>
> This is something I would welcome.
+1! (though it should be optional :D)
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Ulrich Mayring wrote:
>
>> Leo Simons wrote:
>>
>>> class MyComponent implements Configurable
>>> {
>>> public void configure( Configuration config )
>>> {
>>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>>> // possible
>>> m_val = config.getChild("blah").value();
>>> }
>>> }
>>
>>
>> We have invented an application framework on top of Avalon to prevent
>> things like that. Yes, we thought about contributing that to Avalon,
>> but it's pretty hard to come up with something sufficiently general.
>
>
> most interesting! May I ask how? SecurityManager or something like that
> (hmm, would that work...)? Also, may I ask why? You run untrusted
> components?
Actually Leo, this is something I would welcome. As we delve into the world
of distributed components, or remote repositories, we need to ensure that the
unknown components are not given access to too much. IOW, we need to support
untrusted components--but we have been working in the much simpler world of
a trusted environment.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Leo Simons wrote:
>
>> class MyComponent implements Configurable
>> {
>> public void configure( Configuration config )
>> {
>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>> // possible
>> m_val = config.getChild("blah").value();
>> }
>> }
>
> We have invented an application framework on top of Avalon to prevent
> things like that. Yes, we thought about contributing that to Avalon, but
> it's pretty hard to come up with something sufficiently general.
most interesting! May I ask how? SecurityManager or something like that
(hmm, would that work...)? Also, may I ask why? You run untrusted
components?
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
> mind you, that is the case with avalon as well:
>
> class MyComponent implements Configurable
> {
> public void configure( Configuration config )
> {
> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
> // possible
> m_val = config.getChild("blah").value();
> }
> }
We have invented an application framework on top of Avalon to prevent
things like that. Yes, we thought about contributing that to Avalon, but
it's pretty hard to come up with something sufficiently general.
cheers,
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>
>> The choice of how to apply IoC is a matter of taste in many cases. If
>> everything is passed in the constructor, then we have a more atomic
>> construction phase. But in reality no component is used until after the
>> construction phase.
>
> Yep, but you have no control over the order in which the lifecycles
> Compose, Configure, Initialize, Contextualize etc. are called.
depending on how you look at it...you have control using 'type 3', and
you don't have control (its dictated by the framework semantics) using
avalon-framework.
> Everything is collapsed within the constructor and it is assumed that
> the order of construction is irrelevant.
I would say that it is assumed that the component itself will ensure
correct order of construction, if any is required.
> However, it does make a difference whether you initialize an
> unconfigured component or configure an uninitialized component. For
> example, a component that accesses an external resource might need a
> username/password before it can do that. So it is vital that this
> component passes through configuration before initialisation.
>
> Of course it is possible to maintain the correct order in a constructor,
> but it cannot be guaranteed anymore. The component itself decides.
mind you, that is the case with avalon as well:
class MyComponent implements Configurable
{
public void configure( Configuration config )
{
new Thread( getNewWorker() ).start; // quite possible. Wrong, but
// possible
m_val = config.getChild("blah").value();
}
}
in terms of security, its best to look at the avalon lifecycle as a
convention, not as something which is enforced. It is not enforced.
There is no guarantee.
cheers!
- LSD
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=users@avalon.apache.org&msgId=624609
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Berin Loritsch wrote:
>
> The choice of how to apply IoC is a matter of taste in many cases. If
> everything is passed in the constructor, then we have a more atomic
> construction
> phase. But in reality no component is used until after the construction
> phase.
Yep, but you have no control over the order in which the lifecycles
Compose, Configure, Initialize, Contextualize etc. are called.
Everything is collapsed within the constructor and it is assumed that
the order of construction is irrelevant.
However, it does make a difference whether you initialize an
unconfigured component or configure an uninitialized component. For
example, a component that accesses an external resource might need a
username/password before it can do that. So it is vital that this
component passes through configuration before initialisation.
Of course it is possible to maintain the correct order in a constructor,
but it cannot be guaranteed anymore. The component itself decides.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org