cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/a/ blocks/cocoon-core-sample/cocoon...
Date Wed, 09 Jan 2008 03:59:47 GMT
OK. So using PreparedVariableResolver fixes the problems with the 
dependencies. I've committed the change. But I am still getting 1 unit 
test failure in cocoon core - CachingSourceTestCase is failing on line 
88. How could this possibly have anything to do with what I changed?

Ralph Goers wrote:
> Rats. Sorry. I was trying to squeeze that in when I had free time and 
> I just get so used to skipping the tests since every time I've tried 
> to run them my build has failed. I shouldn't have assumed they were 
> still not working.
> To be honest when I was working on this I was just very frustrated at 
> how much more complicated 2.2 is and was just looking for the simplest 
> way to get VariableResolvers working everywhere like it does in 2.1. I 
> spent hours over the weekend trying to get all this working. I should 
> have raised some of these issues on the list before I checked it in:
> 1. Why on earth is VariableResolverFactory doing a lookup on 
> StringTemplateParserVariableResolver.ROLE? Spring is supposed to free 
> you to allow any implementation of an interface - or is 
> StringTemplateParserVariableResolver the only acceptable 
> implementation? (In which case, why is it even configurable via 
> Spring?). It seems to me this should be replaced with 
> VariableResolver.ROLE.
> 2. Does PreparedVariableResolver (the resolver in 2.1) still work?  If 
> it does I can have BridgeElementParser register it and then have 
> SitemapElementParser replace the VariableResolver bean with 
> StringTemplateParserVariableResolver. I'll give this a try and see 
> what happens. Of course, it may have the same dependency problems.
> BTW - I couldn't find a reference to LegacyVariableResolver anywhere. 
> Did you really mean LegacySitemapStringTemplateParser?
> Ralph
> Grzegorz Kossakowski wrote:
>> pisze:
>>> Author: rgoers Date: Sun Jan  6 01:35:48 2008 New Revision: 609282
>>> URL: Log: Created 
>>> XPathXMLFileModule to fix
>>> problems with XMLFileModule. Added getAttributeValue to JXPathHelper 
>>> and changed all references
>>> to getAttribute to use it instead. Moved registration of 
>>> VariableResolver to BridgeElementParser
>>> from SitemapElementParser to make it available to all Avalon 
>>> components (i.e. input modules).
>> Ralph, move of registration of VariableResolver broke[1] our testing 
>> environment because now
>> LegacyVariableResolver is added to the environment for every test 
>> execution but its dependencies
>> (referenced beans) are not. I'm not sure how to fix this at the 
>> moment but I will try to have a look
>> in upcomming days.
>> Anyway, I have a request to all committers: please test your changes 
>> before committing anything.
>> It's just as simple as executing mvn clean install from root directory.
>> [1] 


View raw message