[Pki-devel] Is clone method broken on /PropConfigStore?

[Adam Young]

I've come across a piece of code resistant to the Type safety cleanup,  
and I suspectthat it is broken, and we are lucky that it is never blown up.

CMS.init calls  DBSubsystem.init() which calls PropConfigStore.clone().  
So this code path is executed.

In the file:
http://svn.fedorahosted.org/svn/pki/trunk/pki/base/common/src/com/netscape/cmscore/base/PropConfigStore.java

the clone method calls



   Enumeration subs = getSubStoreNames();

             while (subs.hasMoreElements()) {
                 IConfigStore sub = (IConfigStore)
                     subs.nextElement();

So the collection returned is expected to be filled with instances that 
implement IConfigStore.  However,  looking at getSubStoreNames:

String pname = (String) e.nextElement();
             int i = pname.indexOf('.'); // substores have "."

             if (i != -1) {
             String n = pname.substring(0, i);

                 if (!v.contains(n)) {
                     v.addElement(n);
                 }
             }
         }
         return v.elements();



It is definitely filling the collection with Strings.  My only guess is 
that the collection used does not have any of the paths joined with a 
dot,  so the returned collection is empty.



SVN shows this code was checked in this way during the initial import.  
I'm guessing noone here has touched it.

I'm planning on changing it like this:


-            Enumeration subs = getSubStoreNames();
+            Enumeration<String> subs = getSubStoreNames();

              while (subs.hasMoreElements()) {
-                IConfigStore sub = (IConfigStore)
-                    subs.nextElement();
+               String subName = subs.nextElement();
+
+                IConfigStore sub = (IConfigStore)getSubStore(subName);



If anyone objects,  speak up now.