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]> 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]> 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]> 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]> 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]> 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]> 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]
> >
> > "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"
