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]
