Also lets rename the Java classes from Job* to Task*. And lets add one more attribute into trigger which is 'once="true"'
This is equivalent to count=1 interval=0. The reason I want this is that it means I can use the Task model to start some long running thing in a sensible way. Paul On 10/12/07, Ruwan Linton <[EMAIL PROTECTED]> wrote: > FYI, > > Paul and I had a chat on this and came to a conclusion on the language > syntax of the tasks (earlier so called Jobs). > > Here is the final syntax of the Tasks, > > <task class="org.my.synapse.Task " name="string"> > <property name="stringProp" value="String"/> > <property name="xmlProp"> > <somexml>config</somexml> > </property> > <trigger ([[count="int-value"]? interval="long-value"] | [cron="0 * 1 * * > ?"])/> > </task> > > if the count is not provided for a trigger then it will run forever in given > interval times repeatedly and also removed the crontrigger and simpletrigger > and merged to just a trigger and the differentiation of the cron from simple > is achieved by the presence of cron attribute in the trigger. > > Thanks, > Ruwan > > > On 10/6/07, Ruwan Linton <[EMAIL PROTECTED]> wrote: > > Paul, > > > > Shall we go with *task* and *onAlarm*, we need to finalize this???? > > > > Thanks, > > Ruwan > > > > > > > > On 9/25/07, Ruwan Linton < [EMAIL PROTECTED]> wrote: > > > 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]> wrote: > > > > > > > > > > > > Paul, > > > > > > > > On 9/24/07, Paul Fremantle <[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]> > > > > > > > > > > > > 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]>> 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]>> 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] >> 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]>> 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]>> 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> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > <mailto: [EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > For additional commands, e-mail: > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > <mailto:[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://pzf.fremantle.org > > > > [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://pzf.fremantle.org > > > > [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" > > > > > > > > -- > > > > Ruwan Linton > > http://www.wso2.org - "Oxygenating the Web Services Platform" > > > > -- > > 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] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
