Return null for the name space prefix while it is the default name space

Hi, Tatu, thanks for following this issue.
I did some investigation for this, and find with the following changes, all the stax test cases will look fine.
a. BaseStreamReader.getNamespacePrefix(int index), return null directly.
b. SimpleNsStreamWriter.writerAttribute(String nsURI, String localName, String value), do not throw exception if the prefix value is null.
As mentioned in the mail list, one possible solution is to use a property to control the behavior. while users explicitly configures it, then use the spec compatible return value, and by default, keep the current behavior.
Any thought ? Really appreciated that this could be resolved soon, as we hope to ship the 4.1.* with Geronimo 3.0. Thanks.

I think that the easiest way would be to add a property and add this in 4.1.2. While this is slight deviation from the limit that patch version is not to change API, I think it's warranted here – caller can still pass String value (with appropriate check that property is supported).

Would it be possible to get a patch with unit test to verify this? I can do this, but right now I am swamped with work, which is why things are moving slowly. But it's bit faster to merge things, so I could probably get this done this week if so.

Attach a patch, a system property is introduced to control the behavior.

Ok, modified patch a bit but the basic idea is the same – just make sure to use the right String.
It's probably best to use static constant, since compiler will embed value anyway, meaning that as long as compilation of code that sets property is done with 4.1.2, deployment is fine with 4.1.0 or 4.1.1.

I will release 4.1.2 later tonight since I will be going for a vacation tomorrow, hopefully this works as expected so as not to delay your integration.

Thanks so much, Tatu.

Woodstox 4.1.2 is now out. Please note that I change the actual property name a bit to follow existing conventions (it's defined in WstxInputProperties as well instead of Stax2 API pkg). Otherwise implementation is as expected, and unit tests pass.

Oh crap. I should have thought through the implications of system property, see WSTX-277; JVM makes this bit costly.

I will probably change this such that system property is accessed the first time it is needed, and cached from there on. This should work for expected cases where sysprops are initialized as part of JVM arguments, or within bootstrapping.

Also noticed that there was no way to actually set this using any other mechanism, which is not good either. So I will make its value changeable using std woodstox mechanism as well.

Figured out a reasonable way to resolve the problems, including addition of settability of the property.

(was included in 4.1.2 release)