#1468 Single whitespace in driver properties is ignored when read back from aliases XML file

[Chris B]

For a connection to an Oracle DB I enabled driver property "v$session.osuser" and set the value to a single SPACE (ASCII 32).
This worked perfectly fine for a DB session that was started within the same Squirrel session:
As expected, Oracle showed " " as the OS user for that DB session.

When I closed Squirrel, that property setting was correctly written to SQLAliases23.xml:

<Bean Class="net.sourceforge.squirrel_sql.fw.sql.SQLDriverProperty">
  <isSpecified>true</isSpecified>
  <name>v$session.osuser</name>
  <value> </value>
</Bean>

So far so good.

However, when I started Squirrel again and reconnected to Oracle with that same Alias, Oracle - unexpextedly - showed my actual OS user name for that DB session.

When I closed Squirrel, the property in SQLAliases23.xml was changed, although I did not change or open the Alias / Driver properties in Squirrel:

<Bean Class="net.sourceforge.squirrel_sql.fw.sql.SQLDriverProperty">
  <isSpecified>true</isSpecified>
  <name>v$session.osuser</name>
  <value/>
</Bean>

So it looks like the pure white space in (at least) XML element <value> was ignored when it was read from XML.

In another test I found that leading and trailing spaces (as in " XYZ ") can be read and written back without problems:

<Bean Class="net.sourceforge.squirrel_sql.fw.sql.SQLDriverProperty">
  <isSpecified>true</isSpecified>
  <name>v$session.osuser</name>
  <value>   XYZ   </value>
</Bean>

[Chris B]

Tested in version 4.2.0.

[Gerd Wagner]

I'm able to reproduce the problem. It is due to the XML library SQuirreL uses to read and write Aliases. During reading the library sets all whitespace only values to null/empty. I can't find and don't think there is a way to change this behavior. As Aliases are rather sensitive to many users I will not lightly replace the library.

Sorry, but I'm afraid the problem won't be fixed in the near future.

[Gerd Wagner]

Chris, the issue of SQuirreL's quite old XML library didn't get go of me. The last few days I spend time replacing the old lib by standard Java XML functionality. This fixes your problem.

But as the change concerns most of SQuirreL's configuration files for now I released it as an experimental release only, see
https://sourceforge.net/projects/squirrel-sql/files/experimental/nano2javaXml/

It would be nice if you could check it out. Before you do please back up your SQuirreL user directory.

Gerd

[Chris B]

Hi Gerd,

thanks for digging into this.

I performed some tests with the experimental version ("20210416"), and in general it went pretty well, I think.
No problems with basic functions such as reading, connecting and modifying my existing aliases.
And indeed, I was not able to reproduce the initially reported behaviour with whitespace only values.

I compared SQLAliases23.xml from before and after using it with the experimental version, but no abnormalities.

Since the new Aliases-XML was stored as UTF-8 - and the old was not - I tested the behaviour on special characters such as german umlauts.
In old Aliases-XML "ü" was stored as "& # xfc ;".
The experimental version had no problems to read it correctly ... and to write it correctly as UTF-8 bytes C3 BC.

Only when switching back to Squirrel 4.2 the umlaut "ü" encoded in UTF-8 was not correctly read.
I have no idea if there is a reliable way to handle special characters differently.
But at least I think it would be a good idea to point out this "lack of backward compatibility" in future release notes.

Or do you think it is an option (and makes sense) to use the "&#;"-notation (e.g. "& # xfc ;" for "ü") also in SQLAliases23.xml when UTF-8 encoded ?

[Gerd Wagner]

Thanks for your feedback, Chris.

The changes are now released as a regular snapshot, see
https://sourceforge.net/projects/squirrel-sql/files/3-snapshots/snapshot-20210424_0200/

The backward incompatibilities are mentioned in the release's readme and in SQuirreL's change log.

Gerd