You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/11/17 19:59:58 UTC
[RT] IoC type, well, something
I read Leo Simons story of the little component that could.
The basic idea was...
...that everything should be passed in the
constructor
...that all components are what we would call
ThreadSafe/Singleton, i.e. you get one reference
and can keep it.
Now, suppose I have a component with about 20 parameters and
four other dependencies.
I get a constructor with 24 parameters. And the constructor itself
will be 24 lines of:
this.m_variable = variable;
I hate it when that happens.
So I returned to thinking about how a container can set the values
and start up a component without having to code all those assignment
statements.
Dependencies are easy:
/**
* @@Dependency()
*/
private final MailServer mailServer;
Tells the container to set this field to a MailServer component.
But configuration? Well, suppose we restricted ourselves to this:
Each configurable field in a component implementation is either:
+ A primitive value (double, int, boolean, etc.)
+ A class with a (String) constructor.
+ A class with a (Configuration) constructor.
+ A class that in turn has configurable fields.
Then we can map each configuration entry into a field:
/**
* @@Configuration ("@max-threads")
*/
private final int maxThreads;
/**
* @@Configuration ("background-color")
*/
private final Color backgroundColor;
/**
* @@Configuration ("foreground-color")
*/
private final Color foregroundColor;
class Color {
/**
* @@Configuration ("@red")
*/
int red;
/**
* @@Configuration ("@green")
*/
int green;
/**
* @@Configuration ("@blue")
*/
int blue;
}
And then use a configuration like this:
<component max-threads="8">
<foreground-color red="255" green="255" blue="255"/>
<background-color red="255" green="255" blue="255"/>
</component>
In short, this would allow us to move the setting of fields
to the container. The container can access private fields via the
AccessibleObject.setAccessible, provided that the container class
has the required security permissions (which I assume it can be
given - it is the only class that needs it).
Thoughts?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 18 November 2003 03:13, Stephen McConnell wrote:
> Leo Sutic wrote:
> >In short, this would allow us to move the setting of fields
> >to the container. The container can access private fields via the
> >AccessibleObject.setAccessible, provided that the container class
> >has the required security permissions (which I assume it can be
> >given - it is the only class that needs it).
> >
> >Thoughts?
>
> Maybe I'm just too old fashion - but this is like sleeping with the
> enemy. If I - as component writer declare something as private - then
> what I'm saying is that its off limits to others including the container.
You get what you bargain for; No @field and it is still very private...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> > From: Jonathan Hawkes
> >
> > The container should not have to know about the component's
> > internals.
>
> In a way that is not possible - the container has to know some
> things about a component. Its dependencies, for one.
Only if you want to use it :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] IoC type, well, something
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
> >Thoughts?
> >
>
> Maybe I'm just too old fashion - but this is like sleeping with the
> enemy. If I - as component writer declare something as
> private - then what I'm saying is that its off limits to others
> including the container.
I thought that too. On the other hand, you *have* declared it as a field
where the container should set the value. So it's not like you're not
getting what you asked for.
> From: Jonathan Hawkes
>
> The container should not have to know about the component's
> internals.
In a way that is not possible - the container has to know some
things about a component. Its dependencies, for one.
What I am trying to achieve is to use attributes to make the
container carry out specific actions - i.e. set this field to
that, and so on.
So, the container will not know anything about the internals
that you haven't declared with attributes. This isn't that
different from declaring it in an XML file.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>In short, this would allow us to move the setting of fields
>to the container. The container can access private fields via the
>AccessibleObject.setAccessible, provided that the container class
>has the required security permissions (which I assume it can be
>given - it is the only class that needs it).
>
>Thoughts?
>
Maybe I'm just too old fashion - but this is like sleeping with the
enemy. If I - as component writer declare something as private - then
what I'm saying is that its off limits to others including the container.
Stephen.
--
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: [RT] IoC type, well, something
Posted by Stephen McConnell <mc...@apache.org>.
Jonathan Hawkes wrote:
>Yeah, I don't like it. What I love about the way the framework currently
>works is that a component is still a stand-alone piece of software. It is
>given reference to a ServiceManager and then it can put itself together
>based on its needs. In my opinion, this way of doing things is more in line
>with object-oriented thinking. The container should not have to know about
>the component's internals. This is putting too much of a burden on the
>container. A component should do what it does, and a container should do
>what it does. When everything is doing what its supposed to do, then you
>have a well-designed piece of software. Of course, defining the exact
>responsibilities of the container and of the component is part of what we're
>all about...
>
>
+1
--
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: [RT] IoC type, well, something
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Yeah, I don't like it. What I love about the way the framework currently
works is that a component is still a stand-alone piece of software. It is
given reference to a ServiceManager and then it can put itself together
based on its needs. In my opinion, this way of doing things is more in line
with object-oriented thinking. The container should not have to know about
the component's internals. This is putting too much of a burden on the
container. A component should do what it does, and a container should do
what it does. When everything is doing what its supposed to do, then you
have a well-designed piece of software. Of course, defining the exact
responsibilities of the container and of the component is part of what we're
all about...
Jonathan Hawkes
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: <de...@avalon.apache.org>
Sent: Monday, November 17, 2003 11:59 AM
Subject: [RT] IoC type, well, something
> I read Leo Simons story of the little component that could.
>
> The basic idea was...
>
> ...that everything should be passed in the
> constructor
>
> ...that all components are what we would call
> ThreadSafe/Singleton, i.e. you get one reference
> and can keep it.
>
> Now, suppose I have a component with about 20 parameters and
> four other dependencies.
>
> I get a constructor with 24 parameters. And the constructor itself
> will be 24 lines of:
>
> this.m_variable = variable;
>
> I hate it when that happens.
>
> So I returned to thinking about how a container can set the values
> and start up a component without having to code all those assignment
> statements.
>
> Dependencies are easy:
>
> /**
> * @@Dependency()
> */
> private final MailServer mailServer;
>
> Tells the container to set this field to a MailServer component.
>
> But configuration? Well, suppose we restricted ourselves to this:
>
> Each configurable field in a component implementation is either:
>
> + A primitive value (double, int, boolean, etc.)
>
> + A class with a (String) constructor.
>
> + A class with a (Configuration) constructor.
>
> + A class that in turn has configurable fields.
>
> Then we can map each configuration entry into a field:
>
> /**
> * @@Configuration ("@max-threads")
> */
> private final int maxThreads;
>
> /**
> * @@Configuration ("background-color")
> */
> private final Color backgroundColor;
>
> /**
> * @@Configuration ("foreground-color")
> */
> private final Color foregroundColor;
>
> class Color {
> /**
> * @@Configuration ("@red")
> */
> int red;
>
> /**
> * @@Configuration ("@green")
> */
> int green;
>
> /**
> * @@Configuration ("@blue")
> */
> int blue;
> }
>
> And then use a configuration like this:
>
> <component max-threads="8">
> <foreground-color red="255" green="255" blue="255"/>
> <background-color red="255" green="255" blue="255"/>
> </component>
>
> In short, this would allow us to move the setting of fields
> to the container. The container can access private fields via the
> AccessibleObject.setAccessible, provided that the container class
> has the required security permissions (which I assume it can be
> given - it is the only class that needs it).
>
> Thoughts?
>
> /LS
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
>
> btw, xstream is real cool (if you must xml...) :D. Very fast. KISS. From
> Joe Walnes.
But it doesn't do namespaces, so for any serious XML-futzing it's not
applicable... :-/
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Leo Simons <le...@apache.org>.
peter royal wrote:
> Jason also has some code to go from Configuration -> Beans ->
> Configuration, using XStream, <http://xstream.codehaus.org>. That's in
> Plexus also.
btw, xstream is real cool (if you must xml...) :D. Very fast. KISS. From
Joe Walnes.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by peter royal <pr...@apache.org>.
On Nov 17, 2003, at 1:59 PM, Leo Sutic wrote:
> Dependencies are easy:
>
> /**
> * @@Dependency()
> */
> private final MailServer mailServer;
>
> Tells the container to set this field to a MailServer component.
Jason van Zyl has some code in Plexus to do just that. I think it works
without metadata, ie if a field is of a type that the container knows
about, it sets it.
> <component max-threads="8">
> <foreground-color red="255" green="255" blue="255"/>
> <background-color red="255" green="255" blue="255"/>
> </component>
Jason also has some code to go from Configuration -> Beans ->
Configuration, using XStream, <http://xstream.codehaus.org>. That's in
Plexus also.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
>>From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>>
>>On the other hand, there's
>>
>> The Principle Of Too Much Magic
>>
>>we're introducing a lot of magic:
>>
>> * reflection
>> * a new pseudo-language (rich javadoc attributes)
>> * a new metadata format (javadoc storage in jar)
>> * a new developer tool (compile pseudo-language into
>> metadata format)
>
> I don't agree that we're *adding* magic.
Well, we're making it mandatory. Can't use a component in the style you
propose without using the above. With good ol' plain avalon4, its
possible without any of those. But yes, merlin and fortress already have
all of the above (and no, I'm not ready to start a crusade against
that...yet :D).
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Leo Sutic wrote:
>> ...that all components are what we would call
>> ThreadSafe/Singleton, i.e. you get one reference
>
> actually, the idea at that point was that you may be receiving a proxy
> which implements the lifestyle under the covers...hot swapping is still
> possible even if you keep the reference.....
I have a love/hate relationship with the picocontainer peeps. Everytime
I think of something, they've just finished implementing it:
http://www.picocontainer.org/hotswapping.html
(not intended as yet-another-plug-for-pico, but it does have a nice
picture showing the idea; I'm sure its not actually remotely new :D)
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] IoC type, well, something
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> On the other hand, there's
>
> The Principle Of Too Much Magic
>
> we're introducing a lot of magic:
>
> * reflection
> * a new pseudo-language (rich javadoc attributes)
> * a new metadata format (javadoc storage in jar)
> * a new developer tool (compile pseudo-language into
> metadata format)
I don't agree that we're *adding* magic. We are however replacing the
current set of magic:
+ reflection - yes we use that right now...
+ new pseudo language - replaces the old pseudo-language
+ new metadata format - replaces the old metadata format which
the programmers shouldn't know or care about anyway.
+ new developer tool - replaces the two existing tools (one for
fortress one for merlin).
Will attempt to dissolve your reasoning in another mail, though!
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] IoC type, well, something
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> I am somewhat hoping for you to dissolve my reasoning :D
Well I tried, but I can't come up with a counter-argument. If you
have the requirements that you list - no dependence on tools, high
level of reusability outside of containers and so on, then your
conclusion is completely correct.
What I am trying to get away from is the need for developers to
write a lot of boilerplate code that does nothing but set variables.
Besides, I know that my code will always run in a container.
Just a hypothetical question - if we had Java1.5 and attributes - would
that change your view?
Finally, by having a superclass that implements LogEnabled,
Contextualizable, Configurable and Servicable, I can implement my
RT, so this doesn't really require a change to the container
architecture.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] IoC type, well, something
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> I read Leo Simons story of the little component that could.
>
> The basic idea was...
>
> ...that everything should be passed in the
> constructor
>
> ...that all components are what we would call
> ThreadSafe/Singleton, i.e. you get one reference
> and can keep it.
actually, the idea at that point was that you may be receiving a proxy
which implements the lifestyle under the covers...hot swapping is still
possible even if you keep the reference.....except that if you make
things event-based, the need for pooling goes away again.....damn, I
really need to write a lot of thoughts down :D
> Now, suppose I have a component with about 20 parameters and
> four other dependencies.
>
> I get a constructor with 24 parameters. And the constructor itself
> will be 24 lines of:
>
> this.m_variable = variable;
>
> I hate it when that happens.
re-decompose, encapsulate! Arrive at the concept of the strongly typed,
value-verifying config bean :D
I would also add that with 24 parameters, what we're coming from is 24
lines of
m_variable = m_configuration.getChild( VARIABLE_KEY ).getValue();
> So I returned to thinking about how a container can set the values
> and start up a component without having to code all those assignment
> statements.
>
> Dependencies are easy:
>
> /**
> * @@Dependency()
> */
> private final MailServer mailServer;
<snip/>
> Thoughts?
My gut feeling tells me: BAD BAD BAD BAD. On the one hand, there's
The Principle Of The Lazy Programmer
and it seems like such a nice idea. While we save not a single line of
code (still need the /** @@Dependency() */ line for each field, we do
keep the 'metadata' ("This field is a dependency and hence it is (set
through the constructor|set by the container automagically") closer to
the field declaration.
On the other hand, there's
The Principle Of Too Much Magic
we're introducing a lot of magic:
* reflection
* a new pseudo-language (rich javadoc attributes)
* a new metadata format (javadoc storage in jar)
* a new developer tool (compile pseudo-language into metadata format)
these are pretty big 'sacrifices'. The code is probably slower, unit
testing will probably require special pseudocontainer tools, there's a
learning curve to learn the tools and formats, specifications to write,
documentation to maintain....
...meanwhile, and this is the big alarm bell ringing in my head, our
component isn't really a POJO anymore. Unless we still keep the really
big constructor (and that means not 24 but 48 lines of parameter
setting), there's no practical way to use it outside of a container
(unless you want tons of lines full of reflection code). Bye-bye reuse.
I could babble on a little more, but I think the point's been made. Yet
the temptation of laziness and elegance remains....I am somewhat hoping
for you to dissolve my reasoning :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org