Joerg Heinicke wrote: > Carsten Ziegeler <cziegeler <at> apache.org> writes: > > Carsten, when I recommended the bean map today [1] I wondered how it actually > works. The documentation talks about jar drop-in [2] which does not seem to be > the full truth. Please correct me if I'm wrong ... :)
> > The BeanMap looks for all beans of a particular type. Therefore the beans > needs > to be registered in the application context. Yes, that's true - so you can use the bean map "standalone" without using anything else from the configurator. > So far so good, but here I think > the drop-in fails. Even if the jar includes the configuration the bean does > not > get added automatically to the application context. Only the other parts of > Cocoon Spring configurator enable this functionality. (If that's correct this > should better be added to the BeanMap documentation.) Yes, that's true - the bean map is just a map of some registered beans. Together with the other functionality of the spring configurator you get the automatic configuration stuff - and if such a configuration contains beans for the map, they are added to the map of course. Yepp, I think this needs some clarifications in the docs. > Which class exactly does > this? And how much stuff is hard-coded in it? You don't want to have paths > like > /META-INF/cocoon/spring when using Cocoon Spring configurator independently > from > Cocoon. It's probably not that hard to change but we should do it before > propagating it :) There are constants defined in org.apache.cocoon.spring.configurator.impl.Constants. So changing this is very simple. The whole loading is done through own xml elements (the "settings" element). Most classes in org.apache.cocoon.spring.configurator.impl deals with this stuff. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
