Re: extracting openejb properties into a separate class

[David Blevins]

On Mar 9, 2009, at 11:19 AM, Karan Malhi wrote:
Interesting...

I was thinking that an option could also have a source , for  
example, to
know which property is in effect right now, we would need to know  
whether it
was set as a system property or openejb.xml or something else  
etc.. . To be
able to store that info next to the option would be nice. Something  
like
system --> xyzproperty=false
openejb.xml-->abcproperty=true

I am assuming we providing feature similar to  
OutputGeneratedDescriptors
i.e. dumping properties into a file in a temp directory.

We might be able to hook up something like that.

At the very least it would be nice to log where we searched for a  
given property so that people know which properties could be supplied  
in an openejb-jar.xml for example.

So I got the initial code in there.  Many things are looking cleaner  
already.  Still have to hook up the logging, but that shouldn't be too  
tough.  Since the code is in the loader package, it can't use the  
util.Logger interface directly, I just need to write a little adapter  
that we can plug into the Options instance.  I'll post some examples  
of the log output when I get that hooked in.


-David


On Sun, Mar 8, 2009 at 8:11 PM, David Blevins  
<david.blev...@visi.com>wrote:


On Mar 8, 2009, at 5:34 PM, David Blevins wrote:

Technically speaking the java.util.Properties class will do this  
already
(which I only discovered a few months ago), but you have to pass  
the parent
Properties instance in the constructor of the child properties  
object which
we aren't doing just yet.  We could definitely do this for the  
properties in
the system instance that default to the system properties.


On second thought it doesn't look like such a good idea to rely on  
the
java.util.Properties object inheritance.  The Properties specific  
methods do
the parent delegation nicely, but all java.util.Map methods (size,  
get, set,
keySet, entrySet, values) do not reflect the parent's data.  Seems  
very
error prone.

Here's a little test case:

  public void testPropertiesInheritance() {
      Properties system = new Properties();
      system.setProperty("color", "red");
      system.setProperty("shape", "round");
      system.setProperty("texture", "matte");

      Properties systemInstance = new Properties(system);
      systemInstance.setProperty("color", "orange");
      systemInstance.setProperty("weight", "15");
      systemInstance.setProperty("height", "2");

      // The good parts
      assertEquals("SystemInstance.getProperty(\"shape\")", "round",
systemInstance.getProperty("shape"));
      assertEquals("SystemInstance.getProperty(\"texture\")",  
"matte",
systemInstance.getProperty("texture"));
      assertEquals("SystemInstance.getProperty(\"color\")", "orange",
systemInstance.getProperty("color"));
      assertEquals("SystemInstance.getProperty(\"weight\")", "15",
systemInstance.getProperty("weight"));
      assertEquals("SystemInstance.getProperty(\"height\")", "2",
systemInstance.getProperty("height"));

      ArrayList<?> names =
Collections.list(systemInstance.propertyNames());
      assertEquals("Names.size()", 5, names.size());

      // update "system" and check "systemInstance"
      system.setProperty("shape", "square");
      assertEquals("SystemInstance.getProperty(\"shape\")", "square",
systemInstance.getProperty("shape"));

      // The bad, all java.util.Map methods do not reflect this
inheritance
      assertEquals("SystemInstance.size()", 3,  
systemInstance.size());
      assertEquals("SystemInstance.get(\"shape\")", null,
systemInstance.get("shape"));
      assertEquals("SystemInstance.get(\"texture\")", null,
systemInstance.get("texture"));
      assertEquals("SystemInstance.get(\"color\")", "orange",
systemInstance.get("color"));
      assertEquals("SystemInstance.get(\"weight\")", "15",
systemInstance.get("weight"));
      assertEquals("SystemInstance.get(\"height\")", "2",
systemInstance.get("height"));
  }


-David




--
Karan Singh Malhi