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 00:14:59 GMT
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?


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
> Ralph, move of registration of VariableResolver broke[1] our testing environment because
> 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
> It's just as simple as executing mvn clean install from root directory.
> [1]

View raw message