synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: SynapseObject - Reminder...
Date Mon, 20 Mar 2006 18:56:45 GMT
Soumadeep wrote:
>
> Hi,
>
>  
>
> I like your suggestion; I guess this is what you are proposing.
>
in short: yes. using type="" allows to programatically distinguish
SO-level attributes from other XML elements. probably adding namespace
prefix would be good idea to avoid a clash with other uses of "type"
name ex. so:type="STRING" - also XML Schema typing could be used with
xsi:type='xsd:string' but would require understanding of XML Schema
which does not seem to be necessary ...
>
>  
>
> <ConsumerIdentification>
>
>  <consumer0>
>
>    <CONSUMER_TYPE type="STRING">GOLD</CONSUMER_TYPE>
>
>    <IP_ADDRESS_FROM type="STRING">192.167.6.0</IP_ADDRESS_FROM>
>
>    <IP_ADDRESS_TO type="STRING">192.168.6.255</IP_ADDRESS_TO>
>
>    <HTTP_AUTH_USERNAME type="STRING">john</HTTP_AUTH_USERNAME>
>
>    <WS_SEC_USERNAME type="STRING">john</WS_SEC_USERNAME>
>
if attribute has a string value it could be also directly represented as
XML attribute (code inside SO would need to try first XML attributes and
then look for XML elements with type="") so the above code would be
equivalent to.:
<consumer0 type="GOLD" ip_address_from="192..." .... >

moreover as XML allows element names to be repeated in arrays (sequence)
of elements then such sequence can be naturally represented without need
to make element names unique. for example:

<ConsumerIdentification>
  <consumer type="GOLD" ip_address_from="192..." .... >
    <assignedService>
      <serviceid>stockQuote1</serviceid>
    </assignedService>
  </consumer>  
  <consumer type="SILVER" ip_address_from="192..." .... >
    <assignedService>
      <serviceid>stockQuote1</serviceid>
    </assignedService>
 </consumer>
<ConsumerIdentification>

or even like that if serviceId are the only content inside
assignedService so assignedService wrapper can be removed:

<ConsumerIdentification>
  <consumer type="GOLD" ip_address_from="192..." .... >
    <assignedService>stockQuote1</assignedService>
  </consumer>  
  <consumer type="SILVER" ip_address_from="192..." .... >
    <assignedService>stockQuote1</assignedService>
    <assignedService>stockQuote2</assignedService>
  </consumer>
<ConsumerIdentification>


but anyway that *should* be completely transparent to users of
SynapseObject API.

best,

alek
>
>    <assignedService>
>
>     <serviceid1 type="STRING">stockQuote1</serviceid1>
>
>    </assignedService>
>
>  </consumer0>
>
>  <consumer1>
>
>    <CONSUMER_TYPE type="STRING">SILVER</CONSUMER_TYPE>
>
>    <IP_ADDRESS_FROM type="STRING">192.168.6.255</IP_ADDRESS_FROM>
>
>    <IP_ADDRESS_TO type="STRING">192.168.6.255</IP_ADDRESS_TO>
>
>    <HTTP_AUTH_USERNAME type="STRING">mary</HTTP_AUTH_USERNAME>
>
>    <WS_SEC_USERNAME type="STRING">mary</WS_SEC_USERNAME>
>
>    <assignedService>
>
>     <serviceid1 type="STRING">stockQuote1</serviceid1>
>
>    </assignedService>
>
>  </consumer1>
>
> </ConsumerIdentification>
>
>  
>
> So any element that has a type attribute could be treated as an
> Attribute of an Object rest would be treated as an Object… cool.
>
>  
>
> Soumadeep
>
>  
>
> -----Original Message-----
> *From:* Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> *Sent:* Monday, March 20, 2006 10:49 PM
> *To:* synapse-dev@ws.apache.org
> *Subject:* Re: SynapseObject - Reminder...
>
>  
>
> Vikas wrote:
>
> <Vikas>
>
>  
>
> The basic idea why we do not opt for ADB/XMLBeans or any other
> XSD2Java mechanism is that a user should not be made to re-generate
> schemas and the based-classes in case the xml content changes...
>
> If we opt for SynapseObject, the basic schema remains the same,
> irrespective of the contents defined in the xml..
>
> As mentioned earlier, SynapseObject has only 2 structural constraints..
>
>  * Every SO[SynapseObject] can have either an attribute or
>
> * Another SO as a child..
>
> The number of attributes or their specific details are not of concern
> to the SynapseObject as such...
>
> i think you can use XML just fine without any XML schemas and in such
> case you can write XSynapseObject that has the same functionality as
> SynapseObject but works directly with XML
>
> As you mentioned earlier, XSynapseObject represent XML element and has
> only 2 structural constraints..
>
>  * Every XSO[SynapseObject] can have either an attribute or (XML
> element has XML attributes that are name=value pairs of strings)
>
> * Another SO as a child.. (XML element can have other XML elements as
> children naturally ordered)
>
> The number of attributes or their specific details are not of concern
> to the XSynapseObject as such... (there is no limits on number
> attributes in XML)
>
> XSynapseObject wraps DOM::Element {
>    String getName()
>    String getAttribute(String name)
>    setAttribute(String name, String value);
>    Integer getIntAttr(String name)
>    setInt Attribute(String name, int value);
>    setInt Attribute(String name, Integer value);
>    // the same for long and other primitive types
>    Iterable<String> attributes();
>    Iterable<XSO> elements();
>    Iterable<XSO> elementsWtihName(String name);
>    Iterable<XSO> search( .... )
>    XSO findFirstElementWithName( String elName)
>    XSO findFirstElementWithAttribute( String attrName )
>    // and son on
> }
>
>
>  
>
> So if a user decides to add another attribute, he need not change the
> schema and re-generate the classes...
>
> check
>
>  
>
> The search methods in SO, provide the users with powerful search
> mechanisms without the overhead of switching between XML[and using
> X-Path to search] and the Java representation generated using XSD2Java...
>
> check  - XSO.search()
>
>  
>
> So we basically provide the create/store/read , generating the
> java code capabilities and manipulate them within a single object..
>
> check
>
>  
>
> Since the SO design is not schema or class dependent, any mediator can
> use it and understand it...thus easily allowing mediators to share and
> manipulate data without writing parsers/transformers...
>
> check (this is general property of XML as a _meta_ language)
>
>  
>
> The use-case below, demonstrating the dependency between SLA and CI
> mediators do shed light on the scenario...
>
> if XSO was used
>
>         XSynapseObject person = new SynapseObject("Person");
>         person.setString("firstName", "Alek");
>
>
> it would produce following XML
>
> <Person firstName="Alek">
>
> (the only difference is that in this case firstName attribute is not
> self types - an alternative would be to encode type in inside
> attribute value ex. priority="{int}0" or have attributes as elements
> <priority attrType="int">0</priority> but i do not think either is
> required as typing is hardcoded in the Java cod anyway when
> setInt/getInt is called)
>
>
>  
>
> Thus,
>
> <SynapseObject name="Person">
>
>     <Attribute name="firstName" type="String">Vikas</Attribute>
>
> </SynapseObject>
>
>  
>
> is similar to(in terms of XSD)
>
>  
>
> <SynapseObject name="Person">
>
>     <Attribute name="firstName" type="String">Vikas</Attribute>
>
>     <Attribute name="lastName" type="String">Roonwal</Attribute>
>
> </SynapseObject>
>
>  
>
> The mediator writer can always throw an "ATTRIBUTE MISSING" exception
> or switch to using the new Attribute, without the hassles of schema
> writing or class re-generation..
>
> check - there is no error if there are additional attributes in XML
> and even if XML schemas is used it is possible to declare that unknown
> attributes should be ignored)
>
>  
>
> Comments please...
>
> hope you find that other perspective useful
>
> best,
>
> alek
>
>  
>
> </Vikas>
>
> ps: The link to SynapseObject's code
>
> http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/synapse-SO/
>
>
> >
> > On 3/20/06, Vikas <vikas@infravio.com <mailto:vikas@infravio.com>> wrote:
> >>
> >> Hi..
> >> Maybe i am pushing back the discussion to the first stage..
> >> But throughout this discussion, though people have been commenting on
> >> standard stuff like Axiom/ADB/XMLBeans,etc; I have not seen a single
> >> implementation that covers the full capabilities that SynapseObject
> >> offers...
> >> Maybe I am being naive, but isn't ease of usage that matters for
> Mediator
> >> writers??
> >>
> >> Tried the utility/wrapper class on OMElement, but thought that its
> not going
> >> to work out without the XML structure..
> >> Find the code attached ...
> >>
> >> ~Vikas
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: Hariharasudhan.D
> >> To: synapse-dev@ws.apache.org <mailto:synapse-dev@ws.apache.org>
> >>
> >> Sent: Monday, March 20, 2006 8:56 PM
> >> Subject: Re: SynapseObject - Reminder...
> >>
> >> Hi,
> >>
> >> I was out of this for a while but just wanted to know what is the
> >> co-relation between ADB and xpath in this context. ADB is more of  a
> light
> >> weight  schema compiler and xpath works on xml. How are we marrying
> these
> >> two aren't they parallel?
> >>
> >> The other obvious question is if we already have xmlBeans for data
> binding
> >> then what's the need for ADB?
> >>
> >> Would highly appreciate if  someone can enlighten me on this. FYI, I
> could
> >> not make sense of what Saminda tried to explain. From the use case
> described
> >> below I think SynapseObject would be very useful for handling mediators.
> >>
> >> Hari
> >>
> >> Davanum Srinivas wrote:
> >> i *really* don't see a need for it. Let's make do with standard stuff
> >> like saminda mentioned.
> >>
> >> thanks,
> >> dims
> >>
> >> On 3/20/06, Vikas <vikas@infravio.com <mailto:vikas@infravio.com>>
> wrote:
> >>
> >>
> >> Hi...
> >>
> >> I am using SynapseObject to handle mediator data, it works as an
> extension.
> >> Is there a problem in adding extensions??
> >> Extensions are not compulsary or imposed on others, just for
> convenience...
> >>
> >> But to make things clear and sum up the points:
> >>
> >> The problem is not with using DOM / OM..
> >> Its the XML structure that gives the meaning, the JAVA/in-memory
> >> representation is just an enabler for that..
> >>
> >> I did try writing the 'utility' methods for OM...
> >> But based on a generic XML structure, it just doesn't work out...
> >> The XML representation along with the Utility classes gives
> SynapseObject
> >> the actual strength and the users the ease..
> >>
> >> SynapseObject is not just about ObjectModel [AXIOM/DOM] or about XML
> [the
> >> structure]
> >> or the data-binding [XMLBeans/ ADB]...
> >>
> >> Its a variation in-between, a blend to be more precise...
> >>
> >> The very problem with XPath is that they are based on the XML structure,
> >> change the structure =>change the X-Path...
> >>
> >> But SynapseObject has only 2 structural constraints..
> >> Every object has
> >> * Attributes as child objects
> >> * Has other SynapseObjects
> >> In case I move an attribute from a parent to its child
> SynapseObject, the
> >> search utility takes care of it, In case of an X-Path that mplies
> another
> >> level of ../.. [hope you are not planning to use x-paths which
> always search
> >> throughout i.e [//someName]
> >>
> >> ~Vikas..
> >>
> >> ----- Original Message -----
> >> From: Saminda Abeyruwan
> >>
> >> To: synapse-dev@ws.apache.org <mailto:synapse-dev@ws.apache.org>
> >>
> >> Sent: Monday, March 20, 2006 2:51 PM
> >> Subject: Re: SynapseObject - Reminder...
> >>
> >> Hi Devs,
> >>
> >> My comments are in line,
> >>
> >> On 3/19/06, Soumadeep <soumadeep@infravio.com
> <mailto:soumadeep@infravio.com>> wrote:
> >>
> >>
> >>
> >> Hi,
> >>
> >> One thing I completely agree with Sanjiva is that this has been dragged
> >>
> >> unnecessarily for this long. Let me emphasize here one thing, that the
> >> intension is not to replace the concepts of data binding as used by
> XMLBeans
> >> which is again an Apache project or trying to re-invent what has been
> >> written. To this effect enough reasons have been provided as to why this
> >> approach was taken. For convenience let me give one of the use cases and
> >> reasons for which SynapseObject was proposed:
> >>
> >>
> >> Following reasons is addressed by Axis2 's codegen concepts.
> >>
> >>
> >>
> >>
> >> Reasons:
> >> 1) Java Properties class lets you handle name-value pairs in a very good
> >>
> >> way but when it comes to representing complex objects it becomes very
> >> difficult.
> >>
> >>
> >> 2) Using the concept of data binding introduces a very rigid and tight
> >>
> >> coupling of data and schema. So if the schema changes the underlying
> data
> >> handling mechanism needs to be changed (which includes the
> beans/classes to
> >> hold the complex data structure)
> >>
> >>
> >> This is why there are two entities exists in Axis2. If the xml is schema
> >> compliant i will use XSD2Java, if not i will write my beans and use
> >> BeanUtil.
> >>
> >>
> >>
> >>
> >> 3) Intelligent search features are either driven by xpath/xqueries for
> >>
> >> pure XML or embedded logic if beans are used, SynapseObject has inbuilt
> >> search features by which you can perform complex searches
> >>
> >>
> >> 4) The reason people use Java Properties class is because name-value
> pairs
> >>
> >> can be shared by other class without any dependency. SynapseObject
> is more
> >> like a Properties Class with added features to handle Complex
> Objects and
> >> also allow search features.
> >>
> >>
> >> Synapse is a user of Axis2, so let it be a user of Axis2's XSD2Java,
> >> BeanUtil and Jaxen compliant Xpath.
> >>
> >>
> >>
> >>
> >> Uses Cases:
> >> A) Data-Sharing between mediators: Consumers need to be identified, once
> >>
> >> it's identified the information could be shared by the SLA mediator
> which
> >> depending on a consumer will set the priority. Below is the pseudo
> code of
> >> how this can be achieved using SynapseObject and how datasharing would
> >> become easy.
> >>
> >>
> >> Background Info:
> >> -----------------------
> >> ConsumerIdentification mediator needs to identify a client by the
> >>
> >> following ways:
> >>
> >>
> >> 1) IP {eg. 192.168.5.*}
> >> 2) IP Range {eg. 192.168.5.20- 192.168.5.30}
> >> 3) WS-SEC auth token
> >> 4) HTTP auth token
> >> 5) certificate
> >> (Other factors that need to be considered whether the incoming
> message was
> >>
> >> first encrypted and then signed or was it signed and then encrypted).
> >>
> >>
> >> Let's consider 1) IP
> >>
> >> Using SynapseObject:
> >> ConsumerIdentification
> >> --------------------------------
> >>
> >> xml frag:
> >> <?xml version='1.0' encoding='windows-1252'?>
> >> <SynapseObject name="ci">
> >>
> >>  <SynapseObject name="consumer0">
> >>  <Attribute name="CONSUMER_TYPE" type="String">GOLD</Attribute>
> >>
> >>  <Attribute name="IP_ADDRESS_FROM" type="String">192.168.6.0</Attribute>
> >>
> >>  <Attribute name="IP_ADDRESS_TO" type="String">192.168.6.255</Attribute>
> >>  <Attribute name="HTTP_AUTH_USERNAME" type="String">john</Attribute>
> >>  <Attribute name="WS_SEC_USERNAME" type="String">john</Attribute>
> >>  <SynapseObject name="assignedService">
> >>  <Attribute name="serviceid1"
> >>
> >> type="String">stockQuote1</Attribute>
> >>
> >>
> >>  </SynapseObject>
> >>  </SynapseObject>
> >>  <SynapseObject name="consumer1">
> >>  <Attribute name="CONSUMER_TYPE"
> >>
> >> type="String">SILVER</Attribute>
> >>
> >>
> >>  <Attribute name="IP_ADDRESS_FROM"
> >>
> >> type="String">192.168.6.255</Attribute>
> >>
> >>
> >>  <Attribute name="IP_ADDRESS_TO" type="String">192.167.6.255</Attribute>
> >>  <Attribute name="HTTP_AUTH_USERNAME" type="String">mary</Attribute>
> >>  <Attribute name="WS_SEC_USERNAME" type="String">mary</Attribute>
> >>  <SynapseObject name="assignedService">
> >>  <Attribute name="serviceid1"
> >>
> >> type="String">stockQuote</Attribute>
> >>
> >>
> >>  <Attribute name="ip" type="String">192</Attribute>
> >>  </SynapseObject>
> >>  </SynapseObject>
> >> </SynapseObject>
> >>
> >> Back to square one,
> >>
> >> Above can be written as,
> >> <ci>
> >>  <consumer name="consumer0">
> >>  <type>GOLD</type>
> >>  <ip_address_from>192.168.6.0 </ip_address_from>
> >>  <ip_address_to>192.167.6.255 </ip_address_to>
> >>  <http_auth_username>Mary</http_auth_username>
> >>  <ws_sec_username>Mary</ws_sec_username>
> >>  </consumer>
> >>  <service name="assingedservice">
> >>  <!-- other stuff -->
> >>  </service>
> >>  <consumer name="consumer1">
> >>  <!-- related suff -->
> >>  </consumer>
> >>  <!-- other services or consumers or related stuff -->
> >> </ci>
> >>
> >> which is much more readable,
> >>
> >> If i want intelligent search i use xpath. A lot of users know how to use
> >> xpath, so it's Zero training. If i write simple beans, i can
> populate the
> >> bean objects using BeanUtil. Now in production the above xml should be
> >> schema aware. That's the whole point of inventing schema. So i will use
> >> XSD2Java. Now these technologies are not going to hook into Synapse
> core.
> >>
> >>
> >>
> >>
> >> in the ci mediator code fragment
> >>
> >> // the the requester ip
> >> ip = {get the remote ip from the messageContext/SynapseContext }
> >>
> >> //Identify if the consumer is there and get appropriate details and
> store
> >>
> >> the consumer related details in the messageContext, one more things
> to note
> >> is that storing shared data is by the mediator name itself eg. ci
> >>
> >>
> >> SynapseObject obj =
> >>
> >>
> consumerIdentification.findSynapseObjectByAttributeValueStartingWith(ip);
> >>
> >>
> >> messageContext.setProperty(consumerIdentification.getName(),obj);
> >> obj will contain all the required values if identified!
> >>
> >> SLA
> >> ------
> >>
> >> xml Fragment:
> >>
> >> <SynapseObject name="SLA">
> >>  <SynapseObject name="consumer0">
> >>  <SynapseObject name="Service0">
> >>  <Attribute name="EPR"
> >>
> >> type="String">http://www.webservicex.net/stockquote.asmx</Atrribute>
> >>
> >>
> >>  <Attribute name="priority" type="Integer">0</Attribute>
> >>  </SynapseObject>
> >>
> >>
> >>  <SynapseObject name="Service1">
> >>  <Attribute name="EPR"
> >>
> >> type="String">http://www.webservicex.net/findZIPCode.asmx</Atrribute>
> >>
> >>
> >>  <Attribute name="priority" type="Integer">1</Attribute>
> >>  </SynapseObject>
> >>  </SynapseObject>
> >> </SynapseObject>
> >>
> >> IMHO above xml fragment would treat as the prior.
> >>
> >>
> >>
> >>
> >> in the SLA Mediator code fragment
> >>
> >> //As there is a dependency between the SLA mediator and CI the SLA
> >>
> >> mediator will pick information for its dependency (Note: we also
> proposed a
> >> concept
> >>
> >>
> >> //of MediatorContext which will have dependency and other
> information for
> >>
> >> a particular mediator)
> >>
> >>
> >> Excuse me btw :)
> >>
> >>
> >>
> >>
> >> //Get the identified consumer from the messagecontext
> >> SynapseObject consumerIdentification =
> >>
> >> (SynapseObject)messageContext.getProperty("ci");
> >>
> >>
> >> // get the consumer name and consumer type
> >> String consumerName = consumerIdentification.getName();
> >> String consumerType =
> >>
> >> consumerIdentification.getString("CONSUMER_TYPE");
> >>
> >>
> >> //find the sla details for the identified consumer
> >> SynapseObject consumer =
> >>
> >> sla.findSynapseObjectByAttributeValue(consumerName);
> >>
> >>
> >> String fromAddress =
> >>
> >> (String)synapseMessageContext.getTo();
> >>
> >>
> >> SynapseObject service =
> >>
> >> consumer.findSynapseObjectByAttributeValue(fromAddress );
> >>
> >>
> >> // The priority value would be used by the SLA mediator to forward the
> >>
> >> request to the provider depending on the priority.
> >>
> >>
> >> String priority = service.getString("priority");
> >>
> >> Now as i can understand from the above code fragments, SynaspeObject
> has to
> >> have a hook to Synapse core. As we agreed, SO should be an extension.
> >> Besides, as technology exists for manipulating the required xml, (xpath,
> >> XSD2Java, BeanUtil) for mediators without having a hook to Synapse
> core, why
> >> on earth we make SO a core feature?
> >>
> >> Thank you
> >>
> >> Saminda
> >>
> >>
> >>
> >>
> >> Regards
> >> Soumadeep
> >>
> >>
> >> -----Original Message-----
> >> From: Saminda Abeyruwan [mailto:samindaa@gmail.com]
> >> Sent: Saturday, March 18, 2006 6:59 PM
> >> To: synapse-dev@ws.apache.org <mailto:synapse-dev@ws.apache.org>
> >> Subject: Re: SynapseObject - Reminder...
> >>
> >>
> >> Hi Devs,
> >>
> >> These are my concern regarding SynapseObject,
> >>
> >> If the following XML is considered wrt SynapseObject semantics,
> >>
> >> <SynapseObject name="sla">
> >>  <attribute name="service"
> >>
> >> type="STRING">http://myhost:myport/Service</attribute>
> >>
> >>
> >>  <SynapseObject name="consumer">
> >>  <attribute name="ip" type="STRING">192.9.2.11</attribute>
> >>  </SynapseObject>
> >> </SynapseObject>
> >>
> >> which is similar to,
> >>
> >> <sla>
> >>  <service> http://myhost:myport/Service </service>
> >>  <consumer>
> >>  <ip>192.9.2.11</ip>
> >>  </consumer>
> >> </sla>
> >>
> >> Now if we have Java beans as follows,
> >>
> >> public class sla {
> >>  private String service;
> >>  private Consumer consumer;
> >>
> >>  //getter and setters
> >> }
> >>
> >> public class Consumer {
> >>  private String ip;
> >>
> >>  //getter and setters
> >> }
> >>
> >> and using the Axis2's
> >>
> >> org.apache.axis2.databinding.utils.BeanUtil.getPullParser(Object
> >> beanObject, QName beanName);
> >>
> >>
> >> i can get a XMLStreamReader and build the OMElement i need. And if i
> have
> >>
> >> prior XML, using
> >>
> >>
> >> Object []
> >>
> >> org.apache.axis2.databinding.utils.BeanUtil.deserialize(OMElement
> >> response, Object [] javaTypes); i can fill the bean object.
> >>
> >>
> >> So if I'm a Mediator author, using BeanUtil i can manipulate XML
> with Zero
> >>
> >> training.
> >>
> >>
> >> Now if my XML is schema complaint, using XSD2Java i can generate
> Beans and
> >>
> >> using XX.parse() method i can fill the beans.
> >>
> >>
> >> So what is done by SynapseObject is already done by Axis2's BeanUtil and
> >>
> >> XSD2Java and they can do much more. So IMHO we do not need to
> reinvent the
> >> wheel with SynapseObject.
> >>
> >>
> >> Those are my concerns.
> >>
> >> Thank you
> >>
> >> Saminda
> >>
> >>
> >>
> >>
> >> On 3/17/06, Sanjiva Weerawarana <sanjiva@opensource.lk
> <mailto:sanjiva@opensource.lk>> wrote:
> >>
> >>
> >> On Mon, 2006-03-27 at 18:44 +0530, Vikas wrote:
> >>
> >>
> >> Hi,
> >>
> >> This is regarding the Synapse object proposed by me and Soumadeep...
> >>
> >> For convenience I am putting below the links for reference:
> >>
> >>
> >>
> <http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200602.mbox/%
> <http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200602.mbox/%25>
> >>
> >>
> >>
> >>
> >> 3cPOEHIPNLJGDMKMMBHILOAECICBAA.soumadeep@infravio.com
> <mailto:3cPOEHIPNLJGDMKMMBHILOAECICBAA.soumadeep@infravio.com>
> >>
> >> %3e>
> >>
> >>
> >>
> >>
> >> and the source code has been available in the Scratch
> >> <
> >>
> >>
> http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/synapse-SO
> >>
> >>
> >>
> >>
> >> I feel that it an effective utility and have made use of it in a all
> >> the mediators that I would like to commit . It sure has made handling
> >> mediator's config data easier..
> >> Would be checking in the cleaned up code for SynapseObject as an
> >> extension...Which I guess is OK.
> >>
> >> Please let me know if anyone has any concerns about it??
> >>
> >> I do .. I will write an explanatory reply tomrrow my time .. sorry for
> >> keeping quiet; I've been reading much of this thread but just haven't
> >> had the time to jump in.
> >>
> >> I *will* dive in tomorrow (later today my time really). I'm afraid its
> >> going to have lots of -1s against SynapseObject features :( .. just to
> >> give you a warning of where its going.
> >>
> >> Sanjiva.
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> >>
> >> To unsubscribe, e-mail:
> >>
> >> synapse-dev-unsubscribe@ws.apache.org
> <mailto:synapse-dev-unsubscribe@ws.apache.org>
> >>
> >>
> >>
> >> For additional commands, e-mail: synapse-dev-help@ws.apache.org
> <mailto:synapse-dev-help@ws.apache.org>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Davanum Srinivas : http://wso2.com/blogs/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> synapse-dev-unsubscribe@ws.apache.org
> <mailto:synapse-dev-unsubscribe@ws.apache.org>
> >> For additional commands, e-mail: synapse-dev-help@ws.apache.org
> <mailto:synapse-dev-help@ws.apache.org>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>  ________________________________
> >>  Regards,
> >> Hariharasudhan.D.
> >>
> >>
> >> When I do good, I feel good; when I do bad, I feel bad.That�s my
> religion .
> >> - Abraham Lincoln
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> synapse-dev-unsubscribe@ws.apache.org
> <mailto:synapse-dev-unsubscribe@ws.apache.org> For additional
> >> commands, e-mail: synapse-dev-help@ws.apache.org
> <mailto:synapse-dev-help@ws.apache.org>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> synapse-dev-unsubscribe@ws.apache.org
> <mailto:synapse-dev-unsubscribe@ws.apache.org>
> >> For additional commands, e-mail: synapse-dev-help@ws.apache.org
> <mailto:synapse-dev-help@ws.apache.org>
> >>
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
>
>
>
>
> -- 
> The best way to predict the future is to invent it - Alan Kay


-- 
The best way to predict the future is to invent it - Alan Kay


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Mime
View raw message