incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "Synapse/InProgress/RegistryAccessThoughts" by PaulFremantle
Date Fri, 30 Jun 2006 11:52:01 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by PaulFremantle:
http://wiki.apache.org/incubator/Synapse/InProgress/RegistryAccessThoughts

------------------------------------------------------------------------------
   1. only strings
   1. only loaded from this XML (i.e. not pulling in an external resource)
  
- This proposes changing this. Instead of having each mediator pull XML config or metadata
in its own way, we can extend the properties to support XML, and then have the mediators grab
the XML from the "in-memory" registry.
+ This proposes changing this. Instead of having each mediator pull XML config or metadata
in its own way, we can extend the properties to support XML, and then have the mediators grab
the XML from the "in-memory" registry. This means that we could remove any "src" tags from
mediators and have mediators use a common pattern to access external xml. However, we will
still expect mediators to allow inline XML "right there" so as to make the structure easy
and clear. So an XSLT can be loaded from a file, in which case its specified at the top using
a property; or inlined, when it can be either in a property or in the actual <xslt/>
element.
  
  {{{
  mediator <== property <== (value | inline | src | lookup)
  }}}
  
- So here is the enhanced property xml:
+ So here is the enhanced property xml structure. It must have exactly one of value, src,
key or inline:
  
  {{{
   <property name="foo" [value="string"] [src="url to XML"] [key="string-key"]>
@@ -35, +35 @@

  
  Note that the particular approach of '''<property name="" key=""/>''' is really just
an aliasing mechanism.
  
- If you specify a key then it will lookup the entry *whenever* you use it. Of course we will
optimize cache etc this. 
+ If you specify a key then it will lookup the entry *whenever* you use it. Of course we will
optimize cache etc this. But the semantic is dynamic.
- 
- 
- 
- 
+ We implement this by making getProperty clever:
+ {{{
+ // pseudo code.... this ignores some issues!
+ SynapseEnvironment.getProperty(String key) {
+     Object obj = hashtable.lookup(key);
+     if (obj instanceof o.a.s.DynamicProperty) {
+          XMLRegistry r = this.getRegistry;
+          Object obj = r.lookup(key); // actually would use a cache but ignore that
+     }
+     return obj;
+ }
+ }}}
+ The actual pseudo code we typed was: 
+ {{{
+ 0. registry.lookupIfModified
+ 1. try lookup in hash as property
+ 2. fails, now lookupRegistry
+ 3. XML -> Object
+ 4. Stick in hash under name
+ 5. next time hits on #1
+ }}}
  
  The core in-memory registry is actually the SynapseEnvironment properties model. The other
registry is just a mapping from keys (strings) to XML fragments (OMNode).  
  
@@ -61, +78 @@

  }
  }}}
  
+ In order to make this model efficient, we need to be able to cache objects: Imagine you
have an XSLT that you are looking up from the registry. You want to be able to compile the
XSLT only once. When someone asks for it again, you want to check if its been modified, and
only recompile if it has. 
+ 
+ We haven't yet fully solved this (because we concentrated on the external view) but at least
Paul thinks there is a neater way than the current extension definition approach. The idea
revolves around a given mediator passing over a "XMLtoObjectMapper" back to the SynapseEnvironment
with a given property. Then the property lookup can check if the XML has changed, and only
then rerun the compilation/conversion step.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message