BeanWrapperImpl doesn't delegate Map-creation to propertyEdtior [SPR-3565]

[spring-projects-issues]

Robert Scholte opened SPR-3565 and commented

With the use of a wizardform I'm trying to to fill a command, in this case I want to fill a Map with a Collection of Dates. This means that the BeanWrapperImpl.class is responsible of building the command with use of the configured PropertyEditors

In the method private Object getPropertyValue(PropertyTokenHolder tokens) the readMethod for the Map is called. The result is null, since the propertyEditor is responsible for creating the Map if required / configured.

Althougt the Map is null, there's a check if token.keys != null, which is true, so the code tries to apply indexes and map keys. As expected this is not possible, so a NullValueInNestedPathException is thrown.

IMHO event though the Map is null, you should try to convert value with the registered PrpertyEdtior (by default null is converted to null, so no problem here I guess).

---

Affects: 2.0.5

Issue Links:

• Option to expose empty value instead of NullValueInNestedPathException [SPR-1671] #6368 Option to expose empty value instead of NullValueInNestedPathException

[spring-projects-issues]

Juergen Hoeller commented

This is debatable and has been discussed repeatedly before. The present strategy is that property editors only kick in for the 'leaf values' that are actually to be populated, while everything else is considered as plain property path navigation (without editors involved). This does not only affect Maps but List entries and even plain object references as well.

The simplest solution for the time being is to lazily create those Maps and List entries and navigated objects on demand, i.e. in the corresponding getter method implementations. That usually works quite well and makes programmatic access to those properties nicer too.

Juergen

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.