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.
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. 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?
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.
> 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).
IMO classes with only a few configuration options should carry their
attributes + getters/setters themselves. More complicated configs should
be moved to separate pure POJO beans.
Exactly.
How to manage this for parent-child components? We have many of them.
Who parses the configuration file for the child components created by a
top-level component? Currently we delegate the parsing to the child, but
we can't keep this if we want POJOs/Setters as the configuration.
> c. avalon/phoenix ServiceManager
AFAIK POJOification in progress, or even finished?
I would say in progress.. But we have not made progresses lately.
in progress, sometimes delicate.
sometimes => often
> 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.
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).
> e. verbose + redundant config in environment.xml, *.xinfo
You mean assembly.xml?
Yes, sorry... should have checked that beforehand.
Is there a possibility to avoid that redundancy
in Avalon? Apart from that I find them both quite readable.
You have to do the following:
1. Declare a component
2. Declare for the component, which other components it references
3. Declare for the SM, which components it propagates to each component
4. Implement in the service() method a lookup and typecast.
This is not inversion of control, this is "all stages control".
It is redundant, since James uses full qualified class names everywhere.
With 4.) in place, 2) and 3) become uneccessary, no additional
information is added, being of any use for SM or the component.
So you think that autodiscovery is the way? Imho is not sufficient that
a class implement an interface to say that it is the choosen
implementation for that service, so you'll need the assembly for
non-trivial configurations.
> This is bad (IMHO) even if you do _not_ want to change container.
> For example, look at the unit tests and the setup() methods. much too
> much has to be done there to execute a simple test. this is mock-up
> hell ;-)
I completely agree, but I don't consider this as a blocker for
evaluating different containers or even try to wire some James stuff
together in order to try it inside an OSGi bundle.
Right. BTW, I am not opposing OSGi. There have other containers been
brought into the discussion, like Spring, xbeans, AFAIR. Stefano did a
poll which one should be preferred, with diverging opinions.
My take on this is: Let's fix our components at first, then decide
about switching containers.
Bernd
I almost agree on this, because I think we should stick to avalon as
long as possible ;-) but I think that the configuration thing and the
dependency management thing cannot and will never been container
agnostic, so we'll have to make a choice before and implement it after.
If there was a container providing a good infrastructure for reloadable,
gui administrable configurations I would try to use it. Maybe eclipse
will release its own preference framework sooner or later but it has a
lot of dependencies on SWT and other eclipse bundles.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
