[prev in list] [next in list] [prev in thread] [next in thread]
List: synapse-dev
Subject: Re: Job language syntax in the Synapse configuration
From: "Ruwan Linton" <ruwan.linton () gmail ! com>
Date: 2007-09-25 2:45:49
Message-ID: 672a01200709241933g350313acm275f3d8554ec68a7 () mail ! gmail ! com
[Download RAW message or body]
Hi all,
Here is my proposal 'B' (Plan B in case of a failure in Plan A :D)
I think tag name startup implies it should have only one. That is why Paul
does not want many startup tags to be present in the configuration. So I
propose the following configuration for startups
<syn:task id="firststartup">
<syn:onAlarm class="MessageInjector">
<syn:simpletrigger count="10" interval="5000"/>
<syn:property name="message">
<test xmlns="urn:paul"/>
</syn:property>
<syn:property name="to" value="urn:test"/>
</syn:onAlarm>
</syn:task>
or else
<syn:worker id="firststartup">
<syn:onAlarm class="MessageInjector">
<syn:simpletrigger count="10" interval="5000"/>
<syn:property name="message">
<test xmlns="urn:paul"/>
</syn:property>
<syn:property name="to" value="urn:test"/>
</syn:onAlarm>
</syn:worker>
We can have multiple (tasks / workers) in the synapse configuration (which /
who) are scheduled to (execute / work). I think the notion of the startups
is a set of tasks scheduled to execute in the given times right?
So that we have sequences, endpoints, proxies, entries and *tasks* or
*workers* in the configuration.
This is my last try on this :D , if you all does not agreed to this or a
variation of this I will keep this thread for the day you want to re-factor
this. (I am sure that day will come soon)
Thanks,
Ruwan
On 9/24/07, Asankha C. Perera <asankha@wso2.com> wrote:
>
> I prefer no startup
>
> asankha
>
> Paul Fremantle wrote:
>
> Haha!
>
> That is why I added <startup> :-)
>
> I *really* don't like having lots of <startup> tags. I think its ugly
> as hell. So I'm willing to support either:
>
> 1) one <startup>
> or
> 2) no <startup>
>
> You can tell I feel strongly about this :-)
>
> Paul
>
> On 9/24/07, Ruwan Linton <ruwan.linton@gmail.com> <ruwan.linton@gmail.com> wrote:
>
> Paul,
>
> On 9/24/07, Paul Fremantle <pzfreo@gmail.com> <pzfreo@gmail.com> wrote:
>
> My proposal would be to have an AbstractStartup that implements the id
> (getID/setID) and have every startup implement the id tag. Then we can
> simply get rid of the startup tag and just have any startup as a
> top-level child of <definitions>
>
> That would look the cleanest.
>
> I agree, my only concern *now* is having arbitrary elements in the
> definitions tag. (I know I came up with that idea *earlier*, but now I don't
> like it, after your points on extendability) That is because having every
> types of startups like <job>, <xyz> with mediators also on the top level
> will screw up the configuration readability isn't it?
>
> For example
> <definition>
> <job .../>
> <paul'sJob ..../>
> <myJob />
> <log .../>
> <send .... />
> </definitions>
>
> I am again saying that grouping startups is not the solution for this.
>
> Thanks,
> Ruwan
>
> Paul
>
> On 9/24/07, Ruwan Linton < ruwan.linton@gmail.com> wrote:
>
> Paul,
>
> I still do not agree to one single <startup> tag. One single startup tag
> implies wrapping (grouping) all startups in to one tag right? We had
>
> this
>
> kind of a configuration earlier and dropped these wrapping elements for
>
> the
>
> simplicity and I just don't like grouping the elements in the
>
> configuration.
>
> Here is my point;
> Say we have <job> now, and <xyz> in the future as startup impls, but id
>
> and
>
> may be tracing, statistics (may be in the future) like attributes are
>
> common
>
> to all startups not just to jobs (SimpleQuartzStartup) or even to xyz.
>
> So it
>
> is good to abstract out those common attributes to a higher abstraction
> layer IMO, to *AbstractStartup*.
>
> At the same time if we have multiple startups, it is good to have that
> startup element with its common attributes in the top level so that the
> configuration will be clean. This does not mean we should group all the
> startup elements in to one single startup element, because we have
>
> common
>
> but unique attributes for each and every startup.
>
> WDYT?
>
> BTW: I have done the refactoring up to some extent and will modify that
>
> as
>
> per the discussion (changing the <job> to <onAlarm>).
>
> Do we need to change the class names as well??? I prefer to change those
>
> as
>
> well to have the right transparency...
>
> Thanks,
> Ruwan
>
>
> On 9/24/07, Paul Fremantle <pzfreo@gmail.com> <pzfreo@gmail.com> wrote:
>
> Ok I agree - I've never been good at names :-)
>
> I think there is one more issue. The "onAlarms" are the things that
> should have names.
>
> So the syntax should be
>
> <startup>
>
> <onAlarm id='blah' .../>
> <onAlarm id='foo' ..../>
>
> </startup>
>
> There is no need for multiple <startup> tags that are named.
>
> Finally, should we make it <onStartup> to match onAlarm?
>
> Paul
>
> On 9/24/07, Sanjiva Weerawarana < sanjiva@opensource.lk> wrote:
>
> So .. I think this is not right yet.
>
> The problem is that we're using *two* very generic terms: "startup"
>
> and
>
> "job". I believe that with our current semantics, the prior means
>
> "do
>
> this
>
> as you start up" and the latter means "execute a Java class at a
>
> given
>
> clock ala cron". Is that right?
>
> What I suggest is that we keep <startup> but change <job> to
>
> something
>
> like this:
> <onAlarm class="..">
> <simpleTrigger ..> | <cronTrigger ..>
> <other stuff>
> </onAlarm>
>
> I actually don't like simpleTrigger etc. - I'd prefer something
>
> like:
>
> <timer cron=..> and
> <timer count=.. delay=..>
>
> This way, its clear that <onAlarm> is simply a task executed upon
>
> some
>
> trigger. We currently only have timer triggers but we could later
>
> have
>
> different triggers too.
>
> In the future if we want something other than an alarm triggered
>
> task
>
> executed at init time, then we can have new xml for that and just
>
> have
>
> it
>
> execute. For example, I can see a <log> action being a useful
>
> startup
>
> thing .. log a message to some place when the system starts up? (I
>
> did
>
> say
>
> in the future BTW!)
>
> Sanjiva.
>
> Ruwan Linton wrote:
>
> After deeply looking in to Paul's code on the startup factory and
> serialization, I thought of the syntax again with keeping Paul's
>
> points
>
> about the startup element on this thread in my mind, I think the
> following configuration is clean and clear.
>
> <definitions>
> <startup id="startup1">
> <job class="MessageInjector">
> ......
> </job>
> </ startup>
> <startup id="startup-n">
> <$ANY_TAG_REGISTERED_WITH_STARTUPFINDER ...../>
> </startup>
> </definitions>
>
> (one startup per startup element and there can be number of
>
> startups
>
> in
>
> the synapse def as in proxy definitions)
>
> This syntax will add an id to startups so that we can control them
>
> at
>
> runtime (if needed) because there is an indexing mechanism. This
>
> syntax
>
> will be same as proxy syntax from the configuration point of view.
>
> This also requires a certain amount of refactoring and I am ready
>
> to
>
> go
>
> ahead with that.
>
> Thanks,
> Ruwan
>
> On 9/21/07, *Ruwan Linton* < ruwan.linton@gmail.com<mailto:ruwan.linton@gmail.com> \
> <ruwan.linton@gmail.com>> wrote:
> +1 for the option [3] and I am happy to do the refactoring if
>
> we
>
> have decided to go with this option. (Indeed my original
>
> proposal
>
> was this)
>
> BTW: Serializer does not seem to be working properly.. (When I
>
> tried
>
> to start synapse using a configuration with a startup job it
>
> builds
>
> the job correctly but does not serializes the job on
>
> serializing
>
> the
>
> config (I will look in to this).
>
> Thanks,
> Ruwan
>
>
> On 9/20/07, *Paul Fremantle* < pzfreo@gmail.com
> <mailto:pzfreo@gmail.com> <pzfreo@gmail.com>> wrote:
>
> I'm not sure everyone is clear - maybe its because I
>
> haven't
>
> yet
>
> documented this :-)
>
> There is a new type of extension point called a Startup
>
> with a
>
> Factory... just like Mediators.
> Job is a type of Startup - with its own XML, just like a
>
> mediator
>
> defines its own XML.
>
> So if we added another type of Startup then it would have
>
> a
>
> different
> tagname. So at the moment we can have:
>
> <startup>
> <job....>...</job>
> <asankha>
> <scheduled to work 24x7x265>
> </asankha>
> </startup>
>
> So there are three choices:
>
> 1) Keep a wrapper element for all "startups"
> 2) remove the flexibility to have different startups
> 3) Refactor the code so it can tell if its a startup or a
>
> mediator
>
> when it hits the tag QName and do the right thing for
>
> each.
>
> Paul
>
> On 9/20/07, Asankha C. Perera < asankha@wso2.com
> <mailto: asankha@wso2.com>> wrote:
> >
> > Well.. if we have other types of jobs.. can we do
>
> something
>
> like
>
> >
> > <definitions>
> > ...
> > <job class="x.y.z.Quartz"....>
> > <job class=" a.b.c.Marble"....>
> >
> > ...
> > </definitions>
> >
> > thanks
> > asankha
> >
> > Paul Fremantle wrote:
> > Do you envisage we will have other kinds of Startup or
>
> should
>
> we pull
> > the pluggability for that?
> >
> > Paul
> >
> > On 9/20/07, Asankha C. Perera <asankha@wso2.com
> <mailto:asankha@wso2.com > <asankha@wso2.com>> wrote:
> >
> >
> > Paul
> >
> > Opps.. nope.. the opposite of it..
> >
> > e.g.
> > <definitions>
> > ...
> > <job....>*
> > ....
> > <proxy... >*
> > ....
> > </definitions>
> >
> > thanks
> > asankha
> >
> >
> > Paul Fremantle wrote:
> > I'm not clear from your note, but I think you are
>
> saying
>
> there
>
> should
> > be a top level tag that holds the jobs:
> >
> > e.g.
> >
> > <definitions>
> > <xxxxx>
> > <job>...</job>
> > </xxxxx>
> > ...
> >
> > Is that what you meant?
> >
> > Paul
> >
> > On 9/20/07, Asankha C. Perera < asankha@wso2.com
> <mailto:asankha@wso2.com> <asankha@wso2.com>> wrote:
> >
> >
> > Paul / Ruwan
> >
> > However, I agree we could do it. Thoughts from others?
> >
> > Well.. when we finalized the config language syntax, we
>
> had
>
> a
>
> top level
> > "definitions" and then one or more "proxy", "sequence",
> "endpoint" etc
> > definitions. So I guess the "job" definitions should be
> handled the same for
> > consistency.
> >
> > asankha
> >
> >
> > On 9/20/07, Ruwan Linton < ruwan.linton@gmail.com
> <mailto:ruwan.linton@gmail.com> <ruwan.linton@gmail.com>> wrote:
> >
> >
> > Hi all,
> >
> > For the moment the configuration for the jobs seems to
>
> be
>
> like
>
> following;
> >
> > <definitions>
> > <startup>
> > <job ...../>*
> > </startup>
> > ......
> > </definitions>
> >
> > The <startup> element is wrapping all the jobs. With
>
> compared
>
> to other
> > elements in the configuration like <sequence>,
>
> <endpoint>
>
> and
>
> all they are
> > top level elements even mediators can appear in the top
>
> level
>
> in which case
> > that collection is treated as the main sequence. So I
>
> propose
>
> to bring the
> > <jobs> element to the top level as follows;
> >
> > <definitions>
> > <registry ..../>?
> > <proxy .../>*
> > <sequence .../>*
> > <endpoint ..../>*
> > <job .../>*
> > <localEntry .../>*
> > (mediator)*
> > </definitions>
> >
> > If we do have multiple types of jobs then we can let
>
> the
>
> FactoryFinder to
> > handle that. Is there any particular reason that I am
>
> missing
>
> here? If not
> > shall we bring these jobs to the top level before 1.1
>
> release?
>
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services
>
> Platform"
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com <mailto: paul@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> < http://www.wso2.com> <http://www.wso2.com>
>
>
> ---------------------------------------------------------------------
>
> 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> <synapse-dev-help@ws.apache.org>
>
>
>
>
> --
>
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation;
>
> http://www.opensource.lk/
>
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> synapse-dev-unsubscribe@ws.apache.org
>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.orgpaul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> synapse-dev-unsubscribe@ws.apache.org
>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.orgpaul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> synapse-dev-unsubscribe@ws.apache.org
>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
[Attachment #3 (text/html)]
Hi all,<br><br>Here is my proposal 'B' (Plan B in case of a failure in Plan A \
:D)<br><br>I think tag name startup implies it should have only one. That is why Paul \
does not want many startup tags to be present in the configuration. So I propose the \
following configuration for startups <br><br><syn:task \
id="firststartup"> <br> <syn:onAlarm \
class="MessageInjector"> <br> <syn:simpletrigger \
count="10" interval="5000"/> <br> \
<syn:property name="message"> \
<br> <test xmlns="urn:paul"/> \
<br> </syn:property> <br> <syn:property \
name="to" value="urn:test"/> <br> </syn:onAlarm>
<br></syn:task><br><br>or else<br><br><syn:worker \
id="firststartup"> <br> <syn:onAlarm \
class="MessageInjector"> <br> <syn:simpletrigger \
count="10" interval="5000"/> <br> \
<syn:property name="message"> \
<br> <test xmlns="urn:paul"/> \
<br> </syn:property> <br> <syn:property \
name="to" value="urn:test"/> <br> </syn:onAlarm>
<br></syn:worker><br><br>We can have multiple (tasks / workers) in the synapse \
configuration (which / who) are scheduled to (execute / work). I think the notion of \
the startups is a set of tasks scheduled to execute in the given times right? \
<br><br>So that we have sequences, endpoints, proxies, entries and *tasks* or \
*workers* in the configuration.<br><br>This is my last try on this :D , if you all \
does not agreed to this or a variation of this I will keep this thread for the day \
you want to re-factor this. (I am sure that day will come soon) \
<br><br>Thanks,<br>Ruwan<br><br><div><span class="gmail_quote">On 9/24/07, <b \
class="gmail_sendername">Asankha C. Perera</b> <<a \
href="mailto:asankha@wso2.com">asankha@wso2.com</a>> wrote:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
I prefer no startup <br><span class="sg">
<br>
asankha</span><div><span class="e" id="q_11536f1849af6c07_2"><br>
<br>
Paul Fremantle wrote:
<blockquote type="cite">
<pre>Haha!<br><br>That is why I added <startup> :-)<br><br>I *really* \
don't like having lots of <startup> tags. I think its ugly<br>as hell. So \
I'm willing to support either:<br><br>1) one <startup> <br>or<br>2) no \
<startup><br><br>You can tell I feel strongly about this \
:-)<br><br>Paul<br><br>On 9/24/07, Ruwan Linton <a \
href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> <ruwan.linton@gmail.com></a> wrote:<br> \
</pre> <blockquote type="cite">
<pre>Paul,<br><br>On 9/24/07, Paul Fremantle <a href="mailto:pzfreo@gmail.com" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><pzfreo@gmail.com></a> wrote:<br> \
</pre> <blockquote type="cite">
<pre>My proposal would be to have an AbstractStartup that implements the \
id<br>(getID/setID) and have every startup implement the id tag. Then we \
can<br>simply get rid of the startup tag and just have any startup as a <br>top-level \
child of <definitions><br><br>That would look the cleanest.<br> </pre> \
</blockquote> <pre>I agree, my only concern *now* is having arbitrary elements in \
the<br>definitions tag. (I know I came up with that idea *earlier*, but now I \
don't<br>like it, after your points on extendability) That is because having \
every <br>types of startups like <job>, <xyz> with mediators also on the \
top level<br>will screw up the configuration readability isn't it?<br><br>For \
example<br><definition><br> <job .../><br> <paul'sJob ..../> \
<br> <myJob /><br> <log .../><br> <send .... \
/><br></definitions><br><br>I am again saying that grouping startups is not \
the solution for this.<br><br>Thanks,<br>Ruwan<br><br> </pre> <blockquote \
type="cite"> <pre>Paul<br><br>On 9/24/07, Ruwan Linton < <a \
href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">ruwan.linton@gmail.com</a>> wrote:<br> \
</pre> <blockquote type="cite">
<pre>Paul,<br><br>I still do not agree to one single <startup> tag. One \
single startup tag<br>implies wrapping (grouping) all startups in to one tag right? \
We had<br> </pre> </blockquote>
</blockquote>
<pre>this<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>kind of a configuration earlier and dropped these wrapping elements \
for<br> </pre> </blockquote>
</blockquote>
<pre>the<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>simplicity and I just don't like grouping the elements in the<br> \
</pre> </blockquote>
</blockquote>
<pre>configuration.<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>Here is my point;<br>Say we have <job> now, and <xyz> in the \
future as startup impls, but id<br> </pre> </blockquote>
</blockquote>
<pre>and<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>may be tracing, statistics (may be in the future) like attributes \
are<br> </pre> </blockquote>
</blockquote>
<pre>common<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>to all startups not just to jobs (SimpleQuartzStartup) or even to \
xyz.<br> </pre> </blockquote>
</blockquote>
<pre>So it<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>is good to abstract out those common attributes to a higher \
abstraction<br>layer IMO, to *AbstractStartup*.<br><br>At the same time if we have \
multiple startups, it is good to have that<br>startup element with its common \
attributes in the top level so that the <br>configuration will be clean. This does \
not mean we should group all the<br>startup elements in to one single startup \
element, because we have<br> </pre> </blockquote>
</blockquote>
<pre>common<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>but unique attributes for each and every \
startup.<br><br>WDYT?<br><br>BTW: I have done the refactoring up to some extent and \
will modify that<br> </pre> </blockquote>
</blockquote>
<pre>as<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>per the discussion (changing the <job> to \
<onAlarm>).<br><br>Do we need to change the class names as well??? I prefer to \
change those<br> </pre> </blockquote>
</blockquote>
<pre>as<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>well to have the right \
transparency...<br><br>Thanks,<br>Ruwan<br><br><br>On 9/24/07, Paul Fremantle <a \
href="mailto:pzfreo@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><pzfreo@gmail.com> </a> wrote:<br> \
</pre> <blockquote type="cite">
<pre>Ok I agree - I've never been good at names :-)<br><br>I think \
there is one more issue. The "onAlarms" are the things that<br>should have \
names.<br><br>So the syntax should be<br><br><startup> <br><br> <onAlarm \
id='blah' .../><br> <onAlarm id='foo' \
..../><br><br></startup><br><br>There is no need for multiple \
<startup> tags that are named.<br><br>Finally, should we make it \
<onStartup> to match onAlarm? <br><br>Paul<br><br>On 9/24/07, Sanjiva \
Weerawarana < <a href="mailto:sanjiva@opensource.lk" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">sanjiva@opensource.lk</a>> \
wrote:<br> </pre>
<blockquote type="cite">
<pre>So .. I think this is not right yet.<br><br>The problem is that \
we're using *two* very generic terms: "startup"<br> </pre> \
</blockquote> </blockquote>
</blockquote>
</blockquote>
<pre>and<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>"job". I believe that with our current semantics, the \
prior means<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>"do<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>this<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>as you start up" and the latter means "execute a Java \
class at a<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>given<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>clock ala cron". Is that right?<br><br>What I suggest is that \
we keep <startup> but change <job> to<br> </pre> \
</blockquote> </blockquote>
</blockquote>
</blockquote>
<pre>something<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>like this:<br> <onAlarm class=".."><br> \
<simpleTrigger ..> | <cronTrigger ..><br> <other stuff><br> \
</onAlarm><br><br>I actually don't like simpleTrigger etc. - I'd prefer \
something <br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>like:<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> <timer cron=..> and<br> <timer count=.. \
delay=..><br><br>This way, its clear that <onAlarm> is simply a task \
executed upon<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>some<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>trigger. We currently only have timer triggers but we could \
later<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>have<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>different triggers too.<br><br>In the future if we want something \
other than an alarm triggered<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>task<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>executed at init time, then we can have new xml for that and \
just<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>have<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>it<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>execute. For example, I can see a <log> action being a \
useful<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>startup<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>thing .. log a message to some place when the system starts up? \
(I<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>did<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>say<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>in the future BTW!)<br><br>Sanjiva.<br><br>Ruwan Linton wrote:<br> \
</pre> <blockquote type="cite">
<pre>After deeply looking in to Paul's code on the startup factory \
and<br>serialization, I thought of the syntax again with keeping Paul's<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
<pre>points<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>about the startup element on this thread in my mind, I think \
the<br>following configuration is clean and clear.<br><br><definitions><br> \
<startup id="startup1"><br> <job \
class="MessageInjector"> <br> ......<br> </job><br> </ \
startup><br> <startup id="startup-n"><br> \
<$ANY_TAG_REGISTERED_WITH_STARTUPFINDER ...../><br> \
</startup><br></definitions><br><br>(one startup per startup element and \
there can be number of <br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>startups<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>in<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>the synapse def as in proxy definitions)<br><br>This syntax will \
add an id to startups so that we can control them<br> </pre> \
</blockquote> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>at<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>runtime (if needed) because there is an indexing mechanism. \
This<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>syntax<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>will be same as proxy syntax from the configuration point of \
view.<br><br>This also requires a certain amount of refactoring and I am ready<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>to<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>go<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>ahead with that.<br><br>Thanks,<br>Ruwan<br><br>On 9/21/07, *Ruwan \
Linton* < <a href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">ruwan.linton@gmail.com </a>
<a href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:ruwan.linton@gmail.com></a>> \
wrote:<br><br> +1 for the option [3] and I am happy to do the refactoring if <br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>we<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> have decided to go with this option. (Indeed my original<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>proposal<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> was this)<br><br> BTW: Serializer does not seem to be \
working properly.. (When I<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>tried<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> to start synapse using a configuration with a startup job \
it<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>builds<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> the job correctly but does not serializes the job on<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>serializing<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>the<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> config (I will look in to this).<br><br> Thanks,<br> \
Ruwan<br><br><br> On 9/20/07, *Paul Fremantle* < <a \
href="mailto:pzfreo@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> pzfreo@gmail.com</a>
<a href="mailto:pzfreo@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:pzfreo@gmail.com></a>> \
wrote:<br><br> I'm not sure everyone is clear - maybe its because I <br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>haven't<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>yet<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> documented this :-)<br><br> There is a new type of \
extension point called a Startup<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>with a<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> Factory... just like Mediators.<br> Job is a type \
of Startup - with its own XML, just like a<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>mediator<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> defines its own XML.<br><br> So if we added another \
type of Startup then it would have<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>a<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> different<br> tagname. So at the moment we can \
have:<br><br> <startup><br> <job....>...</job><br> \
<asankha><br> <scheduled to work 24x7x265> <br> \
</asankha><br> </startup><br><br> So there are three \
choices:<br><br> 1) Keep a wrapper element for all "startups"<br> \
2) remove the flexibility to have different startups <br> 3) Refactor the code \
so it can tell if its a startup or a<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>mediator<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> when it hits the tag QName and do the right thing for<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>each.<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> Paul<br><br> On 9/20/07, Asankha C. Perera < <a \
href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">asankha@wso2.com</a> <mailto: <a \
href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">asankha@wso2.com</a>>> wrote:<br> \
><br> > Well.. if we have other types of jobs.. can we do <br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>something<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>like<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> ><br> > <definitions><br> > \
...<br> > <job class="x.y.z.Quartz"....><br> > \
<job class=" a.b.c.Marble"....> <br> ><br> > \
...<br> > </definitions><br> ><br> > thanks<br> \
> asankha<br> ><br> > Paul Fremantle wrote:<br> > \
Do you envisage we will have other kinds of Startup or <br> </pre>
</blockquote>
</blockquote>
</blockquote>
<pre>should<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> we pull<br> > the pluggability for that?<br> \
><br> > Paul<br> ><br> > On 9/20/07, Asankha C. \
Perera <<a href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> asankha@wso2.com</a>
<a href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:asankha@wso2.com ></a>> \
wrote:<br> ><br> ><br> > Paul<br> > <br> \
> Opps.. nope.. the opposite of it..<br> ><br> > e.g.<br> \
> <definitions><br> > ...<br> > <job....>*<br> \
> ....<br> > <proxy... >* <br> > ....<br> > \
</definitions><br> ><br> > thanks<br> > \
asankha<br> ><br> ><br> > Paul Fremantle wrote:<br> \
> I'm not clear from your note, but I think you are <br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>saying<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>there<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> should<br> > be a top level tag that holds the \
jobs:<br> ><br> > e.g.<br> ><br> > \
<definitions><br> > <xxxxx><br> > \
<job>...</job> <br> > </xxxxx><br> > ...<br> \
><br> > Is that what you meant?<br> ><br> > \
Paul<br> ><br> > On 9/20/07, Asankha C. Perera < <a \
href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> asankha@wso2.com</a>
<a href="mailto:asankha@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:asankha@wso2.com></a>> \
wrote:<br> ><br> ><br> > Paul / Ruwan <br> \
><br> > However, I agree we could do it. Thoughts from others?<br> \
><br> > Well.. when we finalized the config language syntax, we<br> \
</pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>had<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>a<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> top level<br> > "definitions" and \
then one or more "proxy", "sequence",<br> \
"endpoint" etc<br> > definitions. So I guess the "job" \
definitions should be <br> handled the same for<br> > \
consistency.<br> ><br> > asankha<br> ><br> \
><br> > On 9/20/07, Ruwan Linton < <a \
href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> ruwan.linton@gmail.com</a>
<a href="mailto:ruwan.linton@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:ruwan.linton@gmail.com></a>> \
wrote:<br> ><br> ><br> > Hi all, <br> ><br> \
> For the moment the configuration for the jobs seems to<br> </pre> \
</blockquote> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>be<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>like<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> following;<br> ><br> > \
<definitions><br> > <startup><br> > <job \
...../>*<br> > </startup><br> > \
......<br>
> </definitions><br> ><br> > The \
<startup> element is wrapping all the jobs. With<br> </pre> \
</blockquote> </blockquote>
</blockquote>
<pre>compared<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> to other<br> > elements in the configuration \
like <sequence>,<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre><endpoint><br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>and<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> all they are<br> > top level elements even \
mediators can appear in the top<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>level<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> in which case<br> > that collection is treated \
as the main sequence. So I<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>propose<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> to bring the<br> > <jobs> element to the \
top level as follows;<br> ><br> > <definitions><br> \
> <registry ..../>?<br> > <proxy .../>* <br> > \
<sequence .../>*<br> > <endpoint ..../>*<br> > \
<job .../>*<br> > <localEntry .../>*<br> > \
(mediator)*<br> > </definitions> <br> ><br> > \
If we do have multiple types of jobs then we can let<br> </pre> \
</blockquote> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>the<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> FactoryFinder to<br> > handle that. Is there \
any particular reason that I am<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>missing<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> here? If not<br> > shall we bring these jobs to \
the top level before 1.1<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>release?<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> ><br> > Thanks,<br> > Ruwan<br> \
><br> > --<br> > Ruwan Linton<br> > <a \
href="http://www.wso2.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> http://www.wso2.org</a> - "Oxygenating \
the Web Services<br> </pre> </blockquote>
</blockquote>
</blockquote>
<pre>Platform"<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> ><br> ><br> ><br> ><br> \
><br> ><br> ><br> ><br> ><br> \
><br> ><br> ><br><br><br> -- <br> Paul \
Fremantle<br> Co-Founder and VP of Technical Sales, WSO2<br> OASIS \
WS-RX TC Co-chair<br><br> blog: <a href="http://pzf.fremantle.org" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> \
http://pzf.fremantle.org</a> <a href="mailto:paul@wso2.com" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">paul@wso2.com</a> <mailto: \
<a href="mailto:paul@wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> paul@wso2.com</a>><br><br> \
"Oxygenating the Web Service Platform", <a href="http://www.wso2.com" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">www.wso2.com</a>
<a href="http://www.wso2.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">< http://www.wso2.com></a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>---------------------------------------------------------------------<br> \
</pre> <blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> To unsubscribe, e-mail:<br> </pre>
</blockquote>
</blockquote>
</blockquote>
<pre><a href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
</pre>
<pre><mailto: <a href="mailto:synapse-dev-unsubscribe@ws.apache.org" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>><br> \
</pre> <blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> For additional commands, e-mail:<br> </pre>
</blockquote>
</blockquote>
</blockquote>
<pre><a href="mailto:synapse-dev-help@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre> <a href="mailto:synapse-dev-help@ws.apache.org" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"><mailto:synapse-dev-help@ws.apache.org></a>
--
Ruwan Linton
<a href="http://www.wso2.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://www.wso2.org</a> - "Oxygenating \
the Web Services Platform"<br><br><br><br><br>--<br>Ruwan Linton<br> <a \
href="http://www.wso2.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://www.wso2.org</a> - "Oxygenating \
the Web Services Platform"<br> </pre> </blockquote>
<pre>--<br>Sanjiva Weerawarana, Ph.D.<br>Founder & Director; Lanka \
Software Foundation;<br> </pre> </blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre><a href="http://www.opensource.lk/" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://www.opensource.lk/</a> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>Founder, Chairman & CEO; WSO2, Inc.; <a \
href="http://www.wso2.com/" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://www.wso2.com/</a> Member; Apache \
Software Foundation; <a href="http://www.apache.org/" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://www.apache.org/</a> Visiting Lecturer; \
University of Moratuwa; <a href="http://www.cse.mrt.ac.lk/" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">http://www.cse.mrt.ac.lk/</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>---------------------------------------------------------------------<br> \
</pre> <blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>To unsubscribe, e-mail:<br> </pre>
</blockquote>
</blockquote>
<pre><a href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre>For additional commands, e-mail: <a \
href="mailto:synapse-dev-help@ws.apache.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
</pre>
</blockquote>
<pre>--<br>Paul Fremantle<br>Co-Founder and VP of Technical Sales, \
WSO2<br>OASIS WS-RX TC Co-chair<br><br>blog: <a href="http://pzf.fremantle.org" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> \
http://pzf.fremantle.org</a> <a href="mailto:paul@wso2.com" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">paul@wso2.com</a>
"Oxygenating the Web Service Platform", <a href="http://www.wso2.com" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">www.wso2.com</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>---------------------------------------------------------------------<br> \
</pre> <blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>To unsubscribe, e-mail:<br> </pre>
</blockquote>
<pre><a href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
</pre>
<blockquote type="cite">
<pre>For additional commands, e-mail: <a \
href="mailto:synapse-dev-help@ws.apache.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
</pre>
</blockquote>
<pre>--<br>Ruwan Linton<br><a href="http://www.wso2.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">http://www.wso2.org</a> - \
"Oxygenating the Web Services Platform"<br> </pre>
</blockquote>
<pre>--<br>Paul Fremantle<br>Co-Founder and VP of Technical Sales, \
WSO2<br>OASIS WS-RX TC Co-chair<br><br>blog: <a href="http://pzf.fremantle.org" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> \
http://pzf.fremantle.org</a> <a href="mailto:paul@wso2.com" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">paul@wso2.com</a>
"Oxygenating the Web Service Platform", <a href="http://www.wso2.com" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">www.wso2.com</a>
</pre>
</blockquote>
<pre>---------------------------------------------------------------------<br> \
</pre> <blockquote type="cite">
<pre>To unsubscribe, e-mail:<br> </pre>
</blockquote>
<pre><a href="mailto:synapse-dev-unsubscribe@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">synapse-dev-unsubscribe@ws.apache.org</a>
</pre>
<blockquote type="cite">
<pre>For additional commands, e-mail: <a \
href="mailto:synapse-dev-help@ws.apache.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">synapse-dev-help@ws.apache.org</a>
</pre>
</blockquote>
<pre>--<br>Ruwan Linton<br><a href="http://www.wso2.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">http://www.wso2.org</a> - \
"Oxygenating the Web Services Platform"<br> </pre>
</blockquote>
<pre> </pre>
</blockquote>
</span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Ruwan Linton<br><a \
href="http://www.wso2.org">http://www.wso2.org</a> - "Oxygenating the Web \
Services Platform"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic