synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: Job language syntax in the Synapse configuration
Date Mon, 24 Sep 2007 09:29:25 GMT
Lets wait for others comments, if no other options than these two I prefer
no <startup>

Thanks,
Ruwan

On 9/24/07, Paul Fremantle <pzfreo@gmail.com> 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 <ruwan.linton@gmail.com> wrote:
> > Paul,
> >
> > On 9/24/07, Paul Fremantle <pzfreo@gmail.com> 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 < ruwan.linton@gmail.com> 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 <pzfreo@gmail.com> 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 < 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > > "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
> > >
> > >
> >
> >
> >
> > --
> > 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
>
> "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
>
>


-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Mime
View raw message