Carsten Ziegeler wrote:
Leszek Gawron wrote:
Yes, I like your idea. Just one simple "include-config" and that's it.
And the use-default-dirs can then be used to turn off including from the
default location which is on by default (If the directories do not
exists this is not concidered an error).
If you want I can implement this (I would not disable the possibility to
do a include and include-beans in the sitemap though).
Would be even better if you described in few words how to do it. Then I
would do it myself and learn a lot.
Sure. The whole code is in the SitemapLanguage class. Now, there is the
evaluation of the property-dir attribute and the like. You just have to
get all "include-config" children of the Configuration object and pass
that into the method creating the settings objects. There you read all
the property files.
The second thing is to replace the "include-config" statements with
"include" and "include-bean" elements in the Configuration object (ok,
this could be solved differently but that approach works) - this is
already done for the default locations.
And this should be more or less everything.
Hackish but should work ... I will get to it tonight/tomorrow.
For now it looks a little bit like chicken egg problem: the settings are
created first and then passed on as a parameter for bean factory to be
created. Building already a spring context you find that you need to
include even more properties.
One VERY important question concerning cocoon core? Why is it based on
spring's BeanFactory and not on ApplicationContext?
I propose to switch from CocoonBeanFactory to CocoonApplicationContext.
WDYT?
I'm +1 for this - the original code I wrote actually used a
CocoonApplicationContext. Daniel had some concerns about it (I think it
was mainly about too many dependencies) and we switched to the simpler
bean factory. Perhaps Daniel recalls why we switched back?
Now I had some problems with the current implementation as well, for
example ServletContextAware is not handled by the bean factory, so I
extended our CocoonBeanFactory to handle this. An application context
already provides this functionality. So, +1 for this.
This is something I have no idea how to do properly. Looking at
AbstractApplicationContext it looks like we can keep current
CocoonBeanFactory and just use it while creating application context.
Unfortunately there is a lot of custom lifecycle code in
CocoonBeanFactory that I do not know how to modify (ServletContextAware
which you mentioned, some preInstantiateSingletons method that does bean
post processing and so on). Any guidelines?
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
