You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2007/07/29 11:00:08 UTC
DNSServer usage in AbstractJamesService.configure()
Hi,
Two Avalon lifecycle method calls on components are configure() and
initialize(), in that order.
AbstractJamesService.configureHelloName() is called from the configure()
method and utilizes DNSServer component.
But unfortunately, DNSServer is not through initialize() itself yet,
where critical fields get set, so it raises a NPE in lookup().
In Phoenix based James it does not seem to be a problem (which I do not
understand), but in Spring currently it is.
configure() should only be used for reading configuration attributes,
not for doing anything more or even calling sibbling components.
I will try now to split configureHelloName() into configureHelloName() +
initializeHelloName().
Does that sound reasonable?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/29/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> Two Avalon lifecycle method calls on components are configure() and
> initialize(), in that order.
>
> AbstractJamesService.configureHelloName() is called from the configure()
> method and utilizes DNSServer component.
> But unfortunately, DNSServer is not through initialize() itself yet,
> where critical fields get set, so it raises a NPE in lookup().
>
> In Phoenix based James it does not seem to be a problem (which I do not
> understand), but in Spring currently it is.
>
> configure() should only be used for reading configuration attributes,
> not for doing anything more or even calling sibbling components.
>
> I will try now to split configureHelloName() into configureHelloName() +
> initializeHelloName().
>
> Does that sound reasonable?
sounds good to me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by norman <no...@apache.org>.
Am Sonntag, den 29.07.2007, 11:00 +0200 schrieb Bernd Fondermann:
> Hi,
>
> Two Avalon lifecycle method calls on components are configure() and
> initialize(), in that order.
>
> AbstractJamesService.configureHelloName() is called from the configure()
> method and utilizes DNSServer component.
> But unfortunately, DNSServer is not through initialize() itself yet,
> where critical fields get set, so it raises a NPE in lookup().
>
> In Phoenix based James it does not seem to be a problem (which I do not
> understand), but in Spring currently it is.
>
> configure() should only be used for reading configuration attributes,
> not for doing anything more or even calling sibbling components.
>
> I will try now to split configureHelloName() into configureHelloName() +
> initializeHelloName().
>
> Does that sound reasonable?
>
> Bernd
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> Stefano,
>
> Thanks for your comment!
>
> I just debugged James(Phoenix) and was very surprised to find that the
> lifecycle calling sequence is traversing deep (all lifecycle methods
> for one component, then for the second) instead of calling one
> lifecycle method for all components, then the next method for all
> components.
>
> I don't know how I got to assume it must be the other way round, but
> this way it makes even less sense to me to have that many lifecycle
> methods and interfaces!
Well, I have been suprised too when I found out this in past.
I think that so many interfaces have been created to provide self
documenting services/components. IMHO, now that I'm getting used to it,
it is not so bad as I thought the first time I used avalon.
About the lifecycle order I think the only contract is that services are
passed around as fully initialized. Everything else is implementation
specific (phoenix does what you debugged, so one component at a time).
The main problem was that there was no documentation, so I only
discovered this while reading the source code for phoenix.
You may be interested in the phoenix classes that manage the lifecycle:
org.apache.avalon.phoenix.containerkit.lifecycle.LifecycleHelper
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor
The root for this sources is here:
http://svn.apache.org/viewvc/avalon/cvs-migration-snapshot/avalon-phoenix/
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> Booting the server is getting really far now. In fact, the server comes
> up (with some tweaking).
>
> That's been a big step forward.
>
> Bernd
Cool!
Having a spring based deployment will really help most java developers
that never heard of avalon/phoenix and want to play with James or embed
it (spring is almost a standard today).
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Bernd Fondermann wrote:
> Stefano,
>
> Thanks for your comment!
>
> I just debugged James(Phoenix) and was very surprised to find that the
> lifecycle calling sequence is traversing deep (all lifecycle methods
> for one component, then for the second) instead of calling one
> lifecycle method for all components, then the next method for all
> components.
>
> I don't know how I got to assume it must be the other way round, but
> this way it makes even less sense to me to have that many lifecycle
> methods and interfaces!
>
> I have to go now to refactor James/Spring bootstrapping. I wonder how
> that ever worked out (as it appeared to) for releases 2.3.0 and .1!
>
> The AbstractJamesService refactoring proposal is retracted.
... and the correct behavior committed to the Spring sandbox.
Thanks again, Stefano, for pointing out what really went wrong!
Booting the server is getting really far now. In fact, the server comes
up (with some tweaking).
That's been a big step forward.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Bernd Fondermann <be...@googlemail.com>.
Stefano,
Thanks for your comment!
I just debugged James(Phoenix) and was very surprised to find that the
lifecycle calling sequence is traversing deep (all lifecycle methods
for one component, then for the second) instead of calling one
lifecycle method for all components, then the next method for all
components.
I don't know how I got to assume it must be the other way round, but
this way it makes even less sense to me to have that many lifecycle
methods and interfaces!
I have to go now to refactor James/Spring bootstrapping. I wonder how
that ever worked out (as it appeared to) for releases 2.3.0 and .1!
The AbstractJamesService refactoring proposal is retracted.
Bernd
On 7/29/07, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
> IIRC this is the right order for initialization:
> enableLogging
> contextualize
> service
> parameterize
> configure
> initialize
> start
>
> So inside call you should have already received fully initialized
> dependencies.
>
> > configure() should only be used for reading configuration attributes,
> > not for doing anything more or even calling sibbling components.
>
> Not sure this is a requirement of the avalon contract at all. Btw
> configure and initialize are called one after the other, with no changes
> to the dependencies in the mean time. Btw if moving code from configure
> to intialize fix your issue, feel free to move that code.
> The point in doing things in configure instead of initialize is to be
> able to catch configurations errors before running through the
> initialization, otherwise everything can be delayed to initialization.
>
> > I will try now to split configureHelloName() into configureHelloName() +
> > initializeHelloName().
> >
> > Does that sound reasonable?
> >
> > Bernd
>
> If this helps +1, but I think you should look for the problem in the
> spring-avalon wrapper as from my understanding there is no avalon
> contract that is fixed by the action you propose.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: DNSServer usage in AbstractJamesService.configure()
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> Hi,
>
> Two Avalon lifecycle method calls on components are configure() and
> initialize(), in that order.
>
> AbstractJamesService.configureHelloName() is called from the configure()
> method and utilizes DNSServer component.
> But unfortunately, DNSServer is not through initialize() itself yet,
> where critical fields get set, so it raises a NPE in lookup().
Weird. If a component depends on another components then Phoenix give
you a fully initialized service.
So if a dnsserver is there (not null) then it should be fully
initialized. AFAIK phoenix never bind uninitialized components (and
that's also why it does not support cyclic dependencies at all).
> In Phoenix based James it does not seem to be a problem (which I do not
> understand), but in Spring currently it is.
I've not looked at your code: how did you implement the lifecycle?
Do you completely initialize dependencies before the service() call?
IIRC this is the right order for initialization:
enableLogging
contextualize
service
parameterize
configure
initialize
start
So inside call you should have already received fully initialized
dependencies.
> configure() should only be used for reading configuration attributes,
> not for doing anything more or even calling sibbling components.
Not sure this is a requirement of the avalon contract at all. Btw
configure and initialize are called one after the other, with no changes
to the dependencies in the mean time. Btw if moving code from configure
to intialize fix your issue, feel free to move that code.
The point in doing things in configure instead of initialize is to be
able to catch configurations errors before running through the
initialization, otherwise everything can be delayed to initialization.
> I will try now to split configureHelloName() into configureHelloName() +
> initializeHelloName().
>
> Does that sound reasonable?
>
> Bernd
If this helps +1, but I think you should look for the problem in the
spring-avalon wrapper as from my understanding there is no avalon
contract that is fixed by the action you propose.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org