Testing a CustomEditorConfigurer in junit

[lally]

Hey all, another question.

I've got this little class to parse Strings into TimeIntervalRanges. I followed everything I could, extending PropertyEditorSupport and its getAsText/setAsText methods. I added this blurb:

<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer"> 
  <property name="customEditors"> 
	<map> 
	  <entry key="edu.vt.iddl.meval.versioning.TimeIntervalRange">
		<bean class="edu.vt.iddl.meval.versioning.TimeIntervalRange" />
	  </entry> 
	</map> 
  </property> 
</bean>

To my configuration file. The other junit tests for that class run fine. As a final test, I wire in a class called Container (which just holds one of these types as a member var (and c'tor arg)).

The context config file's brought in through @ContextConfiguration, and run via @RunWith(SpringJUnit4ClassRunner.class), in maven 2 with surefire 2.4.2.

Is there some workaround to test this basic functionality? Am I missing something obvious?

Thanks in advance!

[Mike Bingham]

What is the name of your property editor class which performs the conversion? It looks like your configuration currently specifies the same class (TimeIntervalRange) for the convertible type and property editor in your CustomEditorConfigurer definition. The property editor should be specified as the value for the map entry in the customEditors property. For example:

<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer"> 
  <property name="customEditors"> 
	<map> 
	  <entry key="edu.vt.iddl.meval.versioning.TimeIntervalRange">
		<bean class="edu.vt.iddl.meval.versioning.TimeIntervalRangeEditor" />
	  </entry> 
	</map> 
  </property> 
</bean>

[lally]

Thanks for replying!

I made TimeIntervalRange a property editor for itself, following an example I pulled out of Spring in Action.

Are there any examples of a working PropertyEditor in any of the spring examples?

Thanks again!

[lally]

Problem fixed.

There was a separate PropertyEditor, and most importantly, it was calling a setValue() that I hadn't noticed.

Thanks Mike!