On 10/2/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote:
>> > a. phoenix lifecycle interfaces
>>
>> What is the problem with them? In another container the Interface might
>> be named Lifecycle and the methods activate() and deactive(). Just
>> refactoring. The question is how the things done in
>> configure/start/stop/initialize/dispose fit into other frameworks.
>
> Three problems:
> 1. component must import lifecycle stuff and becomes container aware
> (_not_ IoC in the narrow sense!)
THis is easy: don't implement interfaces in the main object, create an
extension for that object implementing all of the lifecycle interfaces
needed.
:-) coming up with that solution strategy is easy. implementing this
solution isn't. ;-)
> 2. lifecycle methods cannot simply be "renamed" if there are
> ServiceManagers stored in the component itself (bad. sometimes
> difficult to refactor, when you get the SM in the first call (say:
> initialize()) and need it in the second (say: configure()))
Right. And we should try to isolate the service() call and the
servicemanager references from our code: it should be easy.
not always easy, but: yes.
The most
difficult part is how we currently propagate the ServiceManager to the
Mailets (via Mailet Context).
How should we propagate such dependencies to Mailets?
For Mailets, I don't know. There has been a thread about it and no one
yet came up with a good solution, AFAIR.
> 3. livecycle method of different containers are not neccessarily
> compatible/interchangable
And this is the bigger issue: "container agnostic components" are only
an utopia. As soon as you write not-hello-world componets you will have
requirements for the lifecycle and the dependencies behaviours and this
will need lines of code or much lines of container configurations to be
addressed. Saying that your component is container agnostic simply means
that the component is not complete and will need much more work in order
to make it working in any specific container.
ooh-kaay... do you consider the whole IoC approach,
separation-of-concerns, low coupling, ... as utopia(s)? Up to some
point it works quite well in reality, I think.
>> > b. avalon configuration stuff
>>
>> Yes, some POJOification should be done here, too. Did we decide how to
>> do this?
>
> No, not yet. We have setters on most components, but much of the
> configuration and intialization is still very very dependent on the
> framework. some consider this as being ok, I don't.
I'm happy with avalon lifecycle dependencies: I would like to remove the
Serviceable/ServiceManager stuff (in favor of setters/enabling
interfaces). I would like to not be dependant on the
Avalon-Configuration stuff (I don't know how).
ok, that would be the base for a common goal. it would already be a
great achievement, even when still running under avalon lifecycle.
>> > d. avalon logger (superclass)
>>
>> What do you suppose? I consider this as refactoring. :-)
>
> Well, logging is not a semantical super-construct of a component, it
> is a side-aspect.
> By extending AbstractLogEnabled you hinder more semantically
> beneficial class hierarchies. Bad.
You simply have to remove "extends AbstractLogEnabled", add "implements
LogEnabled" and add 2 methods copied from AbstractLogEnabled and you'll
have fixed this. So this is a non-issue.
a "non-issue"?? From writing unit test/mock up objects I am under the
impression it _is_ an issue, but I will have to have a look again to
come up with concrete examples.
I would like to keep the IoC style for Loggers: I always hated the
static way to access loggers that 99% of projects out there use. One of
the things because Avalon is great is for trying to enforce IoC for
logging (IMO).
IoC loggers are good... never thought about hating those static
loggers, but will consider this for the future ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
