Bug 478224 - MIGRATED_FROM_JIRA: Modify won't work for uppercase attributes
Summary: MIGRATED_FROM_JIRA: Modify won't work for uppercase attributes
Keywords:
Status: CLOSED EOL
Alias: None
Product: penrose
Classification: Retired
Component: Adapter
Version: 2.0
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Endi Sukma Dewata
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 471500
TreeView+ depends on / blocked
 
Reported: 2008-12-27 08:09 UTC by Chandrasekar Kannan
Modified: 2020-03-27 19:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:43:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Chandrasekar Kannan 2008-12-27 08:09:59 UTC
I have a dynamic entry with an attribute called A10 and when I try to execute an the following ldapmodify it seems that all works but in fact the entry is no updated:

$ cat testmodify.ldif
dn: cn=testentry,dc=Example,dc=com
changetype:modify
replace:A10
A10:penrose

I traced back the issue to ModifyRequestBuillder.generatePrimaryRequest(SourceRef) 

it seems that despite the attribute is called "A10" attributeName is set to "a10". The interpreter is fed with this "a10" attribute at ModifyRequestBuilder:107 

 interpreter.set(attributeName, attributeValue); // "a10","penrose"


and the interpreter.eval(fieldMapping) at ModifyRequestBuilder:107 will yield a null because Interpreter.eval(FieldMapping) will invoke get("A10") to retrieve the value at Interpreter.java:151. 


I'm not sure about what is the best way to handle this. i tried the following patch but I'm not sure if it will broke anything else. Here's the patch 

$ diff -b -u3  DefaultInterpreter.old.java DefaultInterpreter.java
--- DefaultInterpreter.old.java 2007-08-30 17:42:02.254000000 +0200
+++ DefaultInterpreter.java     2007-08-30 16:34:00.457125000 +0200
@@ -105,7 +105,10 @@
             }
             return interpreter.get(name);
         }
-        return variables.get(name);
+        Object toReturn = variables.get(name);
+        if (toReturn != null) return toReturn;
+        toReturn = variables.get(name.toLowerCase());
+        return toReturn;
     }

     public Object eval(String script) throws Exception {
@@ -168,4 +171,3 @@
         variables.clear();
     }
 }
-






Additional Comments From endisd dated Thu Jan 24 20:14:42 CST 2008 
It appears that the ApacheDS library used in Penrose 1.2.4 converts the attribute names in modify operations to lower case. Until the problem is fixed, the workaround is to avoid using capital letters in attribute names, or use OpenDS as the front-end.



=========================================================
Issue dump from jira
$VAR1 = {
          'priority' => '3',
          'customFieldValues' => [],
          'project' => 'PENROSE',
          'status' => '5',
          'components' => [
                            {
                              'name' => 'Adapter',
                              'id' => '10011'
                            }
                          ],
          'reporter' => 'ecerulm',
          'key' => 'PENROSE-253',
          'assignee' => 'endisd',
          'summary' => 'Modify won't work for uppercase attributes',
          'id' => '10830',
          'updated' => '2008-01-24 20:14:42.0',
          'votes' => '0',
          'fixVersions' => [],
          'affectsVersions' => [
                               {
                                 'releaseDate' => '2007-07-17 00:00:00.0',
                                 'sequence' => '26',
                                 'name' => 'Penrose-1.2.4',
                                 'released' => 'true',
                                 'id' => '10123',
                                 'archived' => 'false'
                               }
                             ],
          'description' => 'I have a dynamic entry with an attribute called A10 and when I try to execute an the following ldapmodify it seems that all works but in fact the entry is no updated:

$ cat testmodify.ldif
dn: cn=testentry,dc=Example,dc=com
changetype:modify
replace:A10
A10:penrose

I traced back the issue to ModifyRequestBuillder.generatePrimaryRequest(SourceRef) 

it seems that despite the attribute is called "A10" attributeName is set to "a10". The interpreter is fed with this "a10" attribute at ModifyRequestBuilder:107 

 interpreter.set(attributeName, attributeValue); // "a10","penrose"


and the interpreter.eval(fieldMapping) at ModifyRequestBuilder:107 will yield a null because Interpreter.eval(FieldMapping) will invoke get("A10") to retrieve the value at Interpreter.java:151. 


I'm not sure about what is the best way to handle this. i tried the following patch but I'm not sure if it will broke anything else. Here's the patch 

$ diff -b -u3  DefaultInterpreter.old.java DefaultInterpreter.java
--- DefaultInterpreter.old.java 2007-08-30 17:42:02.254000000 +0200
+++ DefaultInterpreter.java     2007-08-30 16:34:00.457125000 +0200
@@ -105,7 +105,10 @@
             }
             return interpreter.get(name);
         }
-        return variables.get(name);
+        Object toReturn = variables.get(name);
+        if (toReturn != null) return toReturn;
+        toReturn = variables.get(name.toLowerCase());
+        return toReturn;
     }

     public Object eval(String script) throws Exception {
@@ -168,4 +171,3 @@
         variables.clear();
     }
 }
-





',
          'created' => '2007-08-30 10:49:50.0',
          'resolution' => '2',
          'type' => '1'
        };


=========================================================

Comment 1 Chandrasekar Kannan 2008-12-27 08:10:01 UTC
Marking bug as MODIFIED as it was already resolved in Jira - PENROSE-253


Note You need to log in before you can comment on or make changes to this bug.