Grouper Users - Open Discussion List

[Scott Koranda <>]

Hi,

I am working with a sandbox deployment of Grouper 2.2.2 using

Debian 7
Java 1.7.0_95 from OpenJDK (7u95-2.6.4-1~deb7u1)
MariaDB 10.0.24
Tomcat 6.0.35 (6.0.35-6+deb7u1)
Apache HTTP Server (2.2.22-13+deb7u6)

I installed Grouper 2.2.2 using grouperInstaller.jar. During
installation I entered the JDBC connection string

jdbc:mysql://localhost:3306/grouper?CharSet=utf8&useUnicode=true&characterEncoding=utf8

Following the details at

https://spaces.internet2.edu/display/Grouper/Grouper+internationalization

I have:

a) made sure that when Tomcat starts -Dfile.encoding=UTF-8 is
passed to the JVM. I also see that it happens to be passed to the JVM
when I run 'sudo -u tomcat 6 ./bin/gsh.sh'

b) made sure that the AJP connector includes the configuration 
URIEncoding="UTF-8"

c) made sure that MariaDB is configured to use UTF-8 by
setting in my.cnf

character_set_server = utf8
collation_server = utf8_bin

d) made sure that the JDBC connection string, as you can see
above, includes the UTF-8 configuration.

Questions:

1) The wiki page above includes the text "You can get a
success message if you are debugging, but this defaults to
off." I did set 

log4j.rootLogger = DEBUG

but when I do 'grep -i utf' of the log files I do not see
anything that looks like a success message.

What specifically should the success message(s) look like?

2) The log file does contain

2016-03-02 09:41:48,132: [pool-2-thread-1] ERROR 
GrouperStartup.verifyUtf8andTransactionsHelper(388) -  - Error: Cannot 
properly read UTF string from resource: grouperUtf8.txt: 'ٹٺٻټكلل'

So this test appears to be failing. I also see that ERROR printed
out when I run GSH despite seeing -Dfile.encoding=utf-8 passed
to the JVM. 

Any idea why that test fails?

3) Using the UI I am able to create a stem with a name that
has "special" UTF-8 characters, including both Latin
characters with accents (GÈANT) and Japanese characters
(ラスを食). I cannot easily find a browser in which the
characters do not render correctly. 

Does this mean that most likely the UTF-8 configuration is
correct and the log message from (2) above is spurious? 

Thanks,

Scott K