cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [2.2] Problems with local input modules
Date Tue, 25 Dec 2007 17:51:36 GMT
Vadim Gritsenko wrote:
> On Dec 20, 2007, at 9:41 AM, Carsten Ziegeler wrote:
> 
>> Vadim Gritsenko wrote:
>>> On Dec 20, 2007, at 4:40 AM, Carsten Ziegeler wrote:
>>>
>>>> I'm not 100% sure, but I have the feeling that the current way of
>>>> resolving the variables in a sitemap is using the root spring context
>>>> but not the application context of the sitemap in question. This is
>>>> just
>>>> a guess.
>>>>
>>>> I get the following error. Before I dig deeper into the problem, can
>>>> someone confirm/deny that my above asumption is correct?
>>>
>>> Confirmed. Problem is that
>>>
>>> There is no "resolver.setManager()" or something to pass in currently
>>> effective manager into VariableResolver so it ends up using global
>>> service manager.
>>>
>> Argh, thanks Vadim - this is something which must be definitly fixed. Do
>> you have an idea how to fix this?
> 
> I don't know how to fix it in "Springy" way...
> 
> I could... since StringTemplateParserVariableResolver is a prototype
> scoped bean, add a service manager setter to it, pass it to
> LegacySubstitutions... Then StringTemplateParser somehow should be made
> aware of current service manager. Since it currently is not a prototype
> scoped bean and interface method 'parseSubstitutions' does not take
> ServiceManager... I'd probably go for extending the interface.
> 
> Is there some Springy thing like block scope which can be used here? Or
> something else which is better than what I suggested? :)
> 
Don't know :( But it seems to me that this whole thing is rather too
complicated - we have bean definition for this "legacy" stuff that never
should be changed by a user. I'm trying to fix this by adding the
StringTemplateParserVariableResolver and some of the other beans as per
sitemap components. I'll do this in our Java code and therefore remove
the extra bean definitions.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message