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:
[EMAIL PROTECTED] pisze:
Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282
URL: http://svn.apache.org/viewvc?rev=609282&view=rev 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]
http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020&projectId=51
