Thanks Julian for looking onto it! Deleting the property first is indeed my workaround for the issue and it works
It's not a big deal (clearly, as it didn't pop up for 6 years or so), but the behaviour was unexpected and seems unnecessarily restrictive to me. It caused a minor production issue for a client in a very generic code-path that hits Oak via Sling's ModifiableValueMap. Given all layers involved I was surprised that I ended up in Oak ;) If my question helps make Oak a little bit better, that's great. If we can clarify the question and document it in the list's archive that's also great. Regards Julian On Wed, Jul 24, 2019 at 6:52 AM Julian Reschke <julian.resc...@gmx.de> wrote: > > On 24.07.2019 05:55, Julian Reschke wrote: > > On 23.07.2019 23:57, Julian Sedding wrote: > >> Hi all > >> > >> Let's assume we have a Node N of primary type "nt:unstructured" with > >> property P that has a String value "foo". > >> > >> Now when we try to change the value of P to a String[] value of > >> ["foo", "bar"] a ValueException is thrown. > >> > >> This behaviour was introduced in OAK-273. Unfortunately the ticket > >> does not give any explanation why this behaviour should be desired. > >> ... > > > > I was curious and looked, and, surprise, I raised this issue back then. > > > > I would assume that this came up while running the TCK. That is, if we > > undo this change, we are likely to see TCK tests failing. > > > > (not sure, but worth trying) > > > > Now that doesn't necessarily mean that the TCK is correct - I'll need > > more time to re-read things. > > > > Best regards, Julian > > FWIW, did you try to delete the property first? > > Best regards, Julian
