Thanks for your suggestions, Mukund too suggested using xml schema typing such as "xsd:String" for type definition, this of course is a better way to represent it. Hopefully, this will resolve the concerns that were raised.
Best regards Soumadeep -----Original Message----- From: Aleksander Slominski [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 12:27 AM To: [email protected] Subject: Re: SynapseObject - Reminder... 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:[EMAIL PROTECTED] > *Sent:* Monday, March 20, 2006 10:49 PM > *To:* [email protected] > *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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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: [email protected] <mailto:[email protected]> > >> > >> 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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > 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: [email protected] <mailto:[email protected]> > >> > >> Sent: Monday, March 20, 2006 2:51 PM > >> Subject: Re: SynapseObject - Reminder... > >> > >> Hi Devs, > >> > >> My comments are in line, > >> > >> On 3/19/06, Soumadeep <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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:[EMAIL PROTECTED] > >> Sent: Saturday, March 18, 2006 6:59 PM > >> To: [email protected] <mailto:[email protected]> > >> 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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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> > >> > >> > >> > >> > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> %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: > >> > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > >> > >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > >> > >> > >> > >> > >> -- > >> Davanum Srinivas : http://wso2.com/blogs/ > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > >> > >> > >> > >> > >> -- > >> ________________________________ > >> 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: > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> For additional > >> commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > >> > > > > > > -- > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
