-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Curious locale issue with bus names #185
Comments
mhh.. why do those issues always appear shortly after I created a release? Maybe I should as Murphy why this always happens... I looked through the code and checked the usages of Using Using integer here is always awkward, because it is confusing (what should transport 1 mean? Or transport 999? A nightmare when debugging). |
Thanks for the fix, our application is now working in the Turkish locale. I've been doing some reading up on this particular problem, seems it is well known. I have never come across this in my entire career, I guess I've been lucky!
Hah, know this one! In order to be able to get a fix to our customer, I have published 4.2.1-SNAPSHOT to our company Artifactory if anyone else is interested.
Yeh, this is an interesting problem. I know you can kind of simulate extending Feel free to close this if you'd rather deal with the improvements separately as the committed fix solves the original problem. |
A user has reported that our software is failing to start on Windows 11 running in a Turkish locale. We are using an embedded DBus daemon here, and use the following code to get a bus address.
This returns
null
on this Turkish installation, but will correctly return a valid address everywhere else.It turns out that it's the
_busType.toUpperCase()
increateDynamicSession()
. This actually results inUN¦X
(the 'I' is actually U+00A6) and so the provider is never found.In
TransportBuilder
, the providers are registered by upper casing the the already upper case names provided by theITransportProvider
implementations, so the upper casing here is effectively a noop,. and the providers are registered with the correct name.So client code can work around this by making sure the already upper-cased
"UNIX"
is always passed when string bus names are used.But it does seem that a better solution is needed inside dbus-java. I suppose using
enum
is probably out because of the pluggable nature of transport providers.The text was updated successfully, but these errors were encountered: