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]

Reply via email to