JCR and escaping apostrophes

[hiteshlad]

Hi,
We're using Alfresco Community 2.0.0 in our custom webapp over JCR/JNDI.  This has worked well for us so far.  One problem we noticed though on our production server is apostrophe (aka single quotes) are replaced with question marks in some of the fields.  I'm just setting them as standard JCR properties.  For example, here is one instance i see in the node browser:

Name: {http://www.company.com/devcenter/model}description   
Value: The Company Project Father?s Day Media Campaign
Type: {http://www.alfresco.org/model/dictionary/1.0}text

Name: {http://www.company.com/devcenter/model}nameExternal   
Value: Father?s Day Media Campaign
Type: {http://www.alfresco.org/model/dictionary/1.0}text
‍‍‍‍‍‍‍‍

That is, the nameExternal and description should read Father's Day, not Father?s Day.  I know that the JCR property with normal single quotes that the user put in.  That code looks like:

oNode.setProperty(NodeConstants.PROPERTY_NAME_EXTERNAL, sNodeName);
oNode.setProperty(NodeConstants.PROPERTY_DESCRIPTION, sDescription);‍‍

Now this is happening on my production RedHat Enterprise Linux 4 server with MySql 5.0, but not on my test RHEL4 server with MySql 4.1 nor my dev Windows XP with MySql 5.0.

Anybody else see this type of problem?

- hitesh

[hiteshlad]

Using this query:

select * from alf_node_properties where string_value like '%father%';‍

and sure enough, the database on the prod environment has the '?' and the database on the test environment has the correct '.

[hiteshlad]

Okay, I figured it out.  The user actually copied the string "Father's Day" from Microsoft Word.  There, the apostrophe isn't a apostrophe.  Using the following code:

for (int i = 0; i < sProject.length(); i++) {
    char c = sProject.charAt(i);
    System.out.println(i + ": " + c + "(" + (int)c + ")");
}‍‍‍‍

I figured out the supposed apostrophe character wasn't ASCII code 39 but in fact code 146:

0: F(70)
1: a(97)
2: t(116)
3: h(104)
4: e(101)
5: r(114)
6: ?(146)
7: s(115)
8: D(68)
9: a(97)
10: y(121)‍‍‍‍‍‍‍‍‍‍‍

It is reasonable for the system not to accept this extended ascii character.

In the end, this is just another case of user error.  I will be putting a check to make sure all the character codes are < 128.

I hope my internal dialog helps other people.
- hitesh

[nikkijuk]

Is your application server JBoss? I am trying to figure out if JCR/JNDI is working with it. So far it seems to me that Tomcat is working fine but JBoss not.

- Jukkis