Bug: IMetadata.loadAnnotations is too strict regarding the annotation type strings

[jamoore]

The rest of the client code allows the use of the following equivalents:

• TagAnnotation
• TagAnnotationI
• ome.model.annotations.TagAnnotation
• omero.model.TagAnnotation
• omero.model.TagAnnotationI

This should be accepted by the method as well. One possible fix would be to take classes rather than strings, so that the mapping would happen transparently.

[jmoore]

(In [8745]) Working around IMetadata.loadAnnotation use of long class names (See #3671)

[jmoore]

Jean-Marie, looking at the workaround:

commit cf656a22949c15ebf228cb3ea18b72aaef5a0391
Author: jmoore <jmoore@05709c45-44f0-0310-885b-81a1db45b4a6>
Date:   Fri Dec 10 19:21:51 2010 +0000

    Working around `IMetadata.loadAnnotation` use of long class names (See #3671)
    
    git-svn-id: file:///home/svn/omero/trunk@8745 05709c45-44f0-0310-885b-81a1db45b4a6

diff --git a/examples/Annotations/retrievetags.m b/examples/Annotations/retrievetags.m
index 8187235..6d758f4 100644
--- a/examples/Annotations/retrievetags.m
+++ b/examples/Annotations/retrievetags.m
@@ -11,7 +11,7 @@ try
     imageIds.add(java.lang.Long(1));
 
     annotationTypes = java.util.ArrayList();
-    annotationTypes.add('TagAnnotation');
+    annotationTypes.add('ome.model.annotations.TagAnnotation');
 
     % Unused

should we add a method: loadAnnotationsByClass or similar? Then any of the values will be accepted. Alternatively, I could re-use the IceMapper code to do the mapping even on strings.

[jburel]

funny enough I was looking at the ticket now too when I released it was major. We could add a new method but the IceMapper? approach is probably better.

[jmoore]

Just pushed more lenient class name handling for IMetadata to my sprint6-server-backlog branch. To test: try passing any of the many forms of class names to a method (or run the test). See other comment for a previous workaround.

[jmoore <josh@…>]

(In [af7aa6b01b1e762836300a0867028b85784bfe13/ome.git] on branch develop) More lenient class mapping in IMetadata (Fix #3671)