> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>
> Leo Sutic wrote:
> > IoC doesn't mean that there's no flow of information from the
> > component to the container, just that *the container has the final
> > word* regarding what is actually *done* with the information.
>
> The way I was looking at it, the container controls when information
> flows, and the component is not allowed to initiate any
> communication on its own ("You shall speak only when spoken to").
> Your definition is much more useful.
>
> thinking...it seems like the "Will only speak when spoken to" is a
> natural property for passive components (ie that don't implement
> startable nor use seperate threads of execution), whereas you
> won't be able to hold it for active components.
"You shall speak only when spoken to" makes sense, but you need to
allow for another order, or interpret "when spoken to" a bit wider:
"You shall speak only when given permission to speak."
+ Speak when spoken to - because if I ask you something, you
should interpret that as an implicit request that you shall
speak to me (tell me the answer).
+ Notify me about things I have told you to notify me about -
because I have given you explicit permission to speak.
Thinking about a little child that is taught that "you shall speak
only when spoken to". However, you should be able to instruct the
kid to "clean your room, and tell me when you are done". In this
case, you set up a callback ("tell me when you are done") and then
make an asynchronous call to the kid ("clean your room"). In the
same way "do your job and notify me about important events":
component.setComponentMonitor (monitor); // Notify me
component.start (); // do your job
(I've use the setXXX pattern just to make the analogy fit better.)
The important thing about IoC is the C - Control. The container
controls how the component speaks. It controls what is done
with the speech. I.e. the component cn yell and scream all it
wants and it will make no difference to the container:
You: "Time to go sleep now."
Kid: "But I don't want to!"
You: "You do." { kid.suspend(); }
A non-IoC is when the component starts to run the container:
You: "Time to go sleep now."
Kid: "But I don't want to!"
You: "Oh well I guess you don't have to, then..."
Kid: "I want ice cream!"
You: "OK, here you are..."
...
> > I have no problem with your use of lookup() to obtain a monitor.
> > Perhaps even more in line would be to use the Context for this,
> > though. (Or are we getting rid of that one in favor of the
> > ServiceManager?)
>
> here we go again :D
Let's not...
> Me, I'm a type 3 convert, and in that world there is no distinction
> between container or component-provided services. Which works.
Sounds OK to me, too.
> > Regarding the multitude of status messages - I don't think
> > that will be any help.
>
> It ties in with the no-logging idea I think. You want the container to
> notify an admin that a component died. It'd be useful for the
> admin to know why that happened. Hence the specific message. And
> since, in java, things die because of exceptions, that's a nice way
> of providing the message.
OK - yep that makes sense. I just don't see the value of propagating
this to the other components other than as a FYI. One shouldn't expect
the other components to actually *help* here.
Makes sense - a broken component is an exceptional state, so we should
use similar objects to describe it (although we won't be throwing
the Exceptions), but as you say, since the root of the broken-ness
probably will be an Exception, just re-using it will be the clearest,
most user-friendly thing.
Even though you'll get a stack trace and a OwwwBrokenThingException
in the logs (not normally considered user-friendly), I think that this
is the
most user-friendlyness we can hope for and what we should aim for.
Exceptions are exceptional. If they break components one should not try
to
hide it, but show as much data as possible, as it is something that
should never happen.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
