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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
>
> Paul,
>
> On 9/24/07, Paul Fremantle <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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* < [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>> 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* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED] > <[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>> 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
> [EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> < http://www.wso2.com> <http://www.wso2.com>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> [EMAIL PROTECTED]
>
> <mailto: [EMAIL PROTECTED]>
>
> For additional commands, e-mail:
>
> [EMAIL PROTECTED]
>
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
>
>
>
> --
>
> 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:
>
> [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://[EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> 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://[EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
>
> [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
