Daniel Fagerstrom pisze:
Don't remember the details. But the main steps are: The Avalon
configuration is translated to a Spring bean configuration, the bean
configuration is used for creating the (Avalon) bean, and the
o.a.c.core.container.spring.avalon.AvalonBeanPostProcessor is used for
handling the Avalon life cycle steps that not has a direct Spring
counter part.
I see, thanks for basic information, for more (if really needed) I'll have to
search the archives or code...
Is it that simple to just ask ServiceManager for Spring component by
using bean id
In general, yes.
and all functionality (like scopes) will just normally work?
Maybe ;)
;)
The current life cycle of resolvers, service managers and object models
and their relations to sub sitemap calls, is really hard to follow. I
think it would be better to try to put all such information in one or
serveral call stacks, and use something like call scope for accessing
the info.
Then the object model could be a facade against the call stack. I doubt
that it is worth the effort to try to extend the current model.
I agree with all of them. More details on implementation can be discussed only if I start to implement something. I think I'll be able to
start hacking just now.
I wonder how to organize my work that I would be able to commit regularly and trunk will not be broken by untested changes. Do you think
that branching a whole trunk into whiteboard is a good idea? I want to branch whole trunk because I presume that I'll have to touch a lot of
modules during whole GSoC.
Of course I would synchronize branch and trunk as regularly as possible.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
