[jitsi-dev] [ibauersachs/dnssecjava] Provide alternatve to the resource bundle mechanism (#7)


#1

Dnssecjava pulls strings from a messages.properties. Unfortunately, Android does not have this mechanism. This results in an exception whenever R.get() is called, e.g.:

Caused by: java.util.MissingResourceException: Can't find resource for bundle 'messages_en_US', key ''
at java.util.ResourceBundle.missingResourceException(ResourceBundle.java:238)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:230)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:139)
at org.jitsi.dnssec.R.<clinit>(R.java:20)
···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7


#2

@techguy613 You might want to have a look at this.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244715690


#3

Any suggestions on how you'd like to handle this instead?

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244724806


#4

I think I would simply inline all the strings into the source code. If I understand it right, these are all exception messages which should not be translated anyway. So what's the resource bundle indirection good for?

Another idea would be a static setter that could be used by Android apps to set the resource bundle in your R class manually. Because Android actually _can_ read resource bundles, it just doesn't support reading them from the classpath like you do.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244726855


#5

Hm, these were meant to be an explanation why a validation failed.

The setter is a good alternative, and as a fallback, returning the key (formatted like in the unit tests: `key:param1:...:paramN`)

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244743233


#6

Ah, that fallback would be perfect. Even without the setter.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244785080


#7

Hey all, the setter sounds good to me. Should I take a crack at it or would you (@ibauersachs) like to make the change yourself?

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244790237


#8

Some help would be very welcome :slight_smile:

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#issuecomment-244790796


#9

Closed #7 via 663beb5293e050fb97a98bb69b6ebc050fe24d3e.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ibauersachs/dnssecjava/issues/7#event-779984692