synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: Job language syntax in the Synapse configuration
Date Mon, 24 Sep 2007 06:54:41 GMT
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>> 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>> 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>> 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>> 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>> 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>
> >
> >         ---------------------------------------------------------------------
> >
> >         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>
> >
> >
> >
> >
> >     --
> >
> >     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.org
paul@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


Mime
View raw message