You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/07/14 21:43:57 UTC
Component start order
The Java implementation model allows components to designate that
they are "eager" init which means that they will be initialized when
the composite they are in is started rather than on first use.
One problem that I ran into with the extension stuff is that the
specification does not say or even allow a user to say in which order
the components will be started.
One option would be to follow a lexical convention and say that
components will be started in the order that they appear in the SCDL.
I have a few reservations about this:
* users may have other criteria for laying out the file (for example
grouping components together)
* this can be confusing in the presence of include elements - users
may want to group
components together in an include that would fit in different
places in the start order
Instead I'd like to propose we support an init-level indicator like
the run level from Unix systems. Components would be started in
ascending order of the init level they provided.
This could be done as an attribute on the <component> element,
something like:
<component name="start2nd" initLevel="20"> ...
<component name="start1st" initLevel="10"> ...
This would also allow us to eagerly initialize components without
having to use an @Init annotation.
Seem reasonable?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 14, 2006, at 12:43 PM, Jeremy Boynes wrote:
>
> Instead I'd like to propose we support an init-level indicator like
> the run level from Unix systems. Components would be started in
> ascending order of the init level they provided.
>
> This could be done as an attribute on the <component> element,
> something like:
>
> <component name="start2nd" initLevel="20"> ...
> <component name="start1st" initLevel="10"> ...
>
> This would also allow us to eagerly initialize components without
> having to use an @Init annotation.
I added support for this over the weekend, at least on the
<component> definition. Support is in the runtime to support this on
a componentType but I have not changed the loader yet. I have not
done anything with annotations as from what we were talking about it
sounded like we would need spec changes. The boolean eager=true
option on @Init is implemented as setting an initLevel of 50.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I don't think this is an "init" specific issue. To me, it's more about how
to define dependencies for components. If one component A is required to be
initialized before component B, it hints that Component B has a dependency
on Component A.
I remember that Jeremy was proposing to use maven style to lable composites
with group/artifact ids so that a composite version can be identified and
loaded. I guess the maven dependency declarations can also be applied here.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Friday, July 14, 2006 12:43 PM
Subject: Component start order
> The Java implementation model allows components to designate that they
> are "eager" init which means that they will be initialized when the
> composite they are in is started rather than on first use.
>
> One problem that I ran into with the extension stuff is that the
> specification does not say or even allow a user to say in which order the
> components will be started.
>
> One option would be to follow a lexical convention and say that
> components will be started in the order that they appear in the SCDL. I
> have a few reservations about this:
> * users may have other criteria for laying out the file (for example
> grouping components together)
> * this can be confusing in the presence of include elements - users may
> want to group
> components together in an include that would fit in different places in
> the start order
>
> Instead I'd like to propose we support an init-level indicator like the
> run level from Unix systems. Components would be started in ascending
> order of the init level they provided.
>
> This could be done as an attribute on the <component> element, something
> like:
>
> <component name="start2nd" initLevel="20"> ...
> <component name="start1st" initLevel="10"> ...
>
> This would also allow us to eagerly initialize components without having
> to use an @Init annotation.
>
> Seem reasonable?
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jim Marino <jm...@myromatours.com>.
Sounds good to me. Perhaps on Scope? What do others think?
Jim
On Jul 14, 2006, at 5:58 PM, Jeremy Boynes wrote:
> On Jul 14, 2006, at 2:12 PM, Jim Marino wrote:
>>>> What if we said eager init is a component type concept and is
>>>> true or false (specified on @Scope)? Then, run level is the SCDL
>>>> configuration of eager init. So, a component would be eager
>>>> initialized based on the component type info and would be done
>>>> so in the order specified by the SCDL runlevel attribute. If no
>>>> runlevel attribute were present, we would default it to some
>>>> level (maybe 100).
>>>
>>> I'm not sure that whether something is eagerly initialized is a
>>> component-type level concept. I don't think that all usages of an
>>> implementation will require that - some may be eager init, some
>>> may not. With that thinking, whether to eager init and with what
>>> priority would be a component level concept.
>>>
>> Eager init may be one of those half-way concepts. In some cases a
>> dev may want to always eagerly initialize something -e.g.
>> something that performs some action when a scope comes into
>> existence. I could probably go either way. When would we have the
>> case some configurations are eager on others not?
>
> How about we support designation at the component-type level (in
> the sidefile or by annotation) that allows the developer to specify
> the default level? The presence of a default would imply eager init.
>
> This can be overridden at the component level by specifying a
> different level or by allowing eager init to be disabled.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 14, 2006, at 2:12 PM, Jim Marino wrote:
>>> What if we said eager init is a component type concept and is
>>> true or false (specified on @Scope)? Then, run level is the SCDL
>>> configuration of eager init. So, a component would be eager
>>> initialized based on the component type info and would be done so
>>> in the order specified by the SCDL runlevel attribute. If no
>>> runlevel attribute were present, we would default it to some
>>> level (maybe 100).
>>
>> I'm not sure that whether something is eagerly initialized is a
>> component-type level concept. I don't think that all usages of an
>> implementation will require that - some may be eager init, some
>> may not. With that thinking, whether to eager init and with what
>> priority would be a component level concept.
>>
> Eager init may be one of those half-way concepts. In some cases a
> dev may want to always eagerly initialize something -e.g. something
> that performs some action when a scope comes into existence. I
> could probably go either way. When would we have the case some
> configurations are eager on others not?
How about we support designation at the component-type level (in the
sidefile or by annotation) that allows the developer to specify the
default level? The presence of a default would imply eager init.
This can be overridden at the component level by specifying a
different level or by allowing eager init to be disabled.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 14, 2006, at 1:58 PM, Jeremy Boynes wrote:
> On Jul 14, 2006, at 1:05 PM, Jim Marino wrote:
>> I'm wondering if specifying the start level in SCDL is crossing
>> semantics with eager init...
>>
>> As background, one thing I was planning on proposing to the spec
>> was moving eager init off of @Init and onto @Scope for couple of
>> reasons. First, eagerness is associated with the scope, not an
>> initializer callback, IMO. The second reason is that it avoids a
>> problem I've been noticing lately where I want to eager init
>> something but I don't need an initializer callback, and I am
>> forced to add an empty method just to get the component to be
>> instantiated eagerly. Couple that with constructor-based
>> injection, and I think it is better to but things on @Scope.
>
> I've hit this issue as well and it's annoying :-)
> I think we still need initializer callbacks but that is independent
> of whether initialization is eager or not.
>
> Adding this to @Scope seems odd but I can't think of a better place
> right now. I think this would be the default runlevel for this
> component type (see below on why I think it should be configurable
> per-component).
>
>> What if we said eager init is a component type concept and is true
>> or false (specified on @Scope)? Then, run level is the SCDL
>> configuration of eager init. So, a component would be eager
>> initialized based on the component type info and would be done so
>> in the order specified by the SCDL runlevel attribute. If no
>> runlevel attribute were present, we would default it to some level
>> (maybe 100).
>
> I'm not sure that whether something is eagerly initialized is a
> component-type level concept. I don't think that all usages of an
> implementation will require that - some may be eager init, some may
> not. With that thinking, whether to eager init and with what
> priority would be a component level concept.
>
Eager init may be one of those half-way concepts. In some cases a dev
may want to always eagerly initialize something -e.g. something that
performs some action when a scope comes into existence. I could
probably go either way. When would we have the case some
configurations are eager on others not?
>> Also, I think we should have a default runlevel attribute on
>> composites as well that applies to all children. This may be
>> implicit in the above since composites are just components.
>
> I was thinking order applied within a composite to the components
> of a composite (either direct children or ones from include's). You
> could specify an initLevel on a component implemented by a
> composite but that would determine the order in which the sub-
> composite as a whole was started; any order applied to components
> in the sub-composite would be independent of the order of those in
> the parent.
>
Yes good point.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 14, 2006, at 1:05 PM, Jim Marino wrote:
> I'm wondering if specifying the start level in SCDL is crossing
> semantics with eager init...
>
> As background, one thing I was planning on proposing to the spec
> was moving eager init off of @Init and onto @Scope for couple of
> reasons. First, eagerness is associated with the scope, not an
> initializer callback, IMO. The second reason is that it avoids a
> problem I've been noticing lately where I want to eager init
> something but I don't need an initializer callback, and I am forced
> to add an empty method just to get the component to be instantiated
> eagerly. Couple that with constructor-based injection, and I think
> it is better to but things on @Scope.
I've hit this issue as well and it's annoying :-)
I think we still need initializer callbacks but that is independent
of whether initialization is eager or not.
Adding this to @Scope seems odd but I can't think of a better place
right now. I think this would be the default runlevel for this
component type (see below on why I think it should be configurable
per-component).
> What if we said eager init is a component type concept and is true
> or false (specified on @Scope)? Then, run level is the SCDL
> configuration of eager init. So, a component would be eager
> initialized based on the component type info and would be done so
> in the order specified by the SCDL runlevel attribute. If no
> runlevel attribute were present, we would default it to some level
> (maybe 100).
I'm not sure that whether something is eagerly initialized is a
component-type level concept. I don't think that all usages of an
implementation will require that - some may be eager init, some may
not. With that thinking, whether to eager init and with what priority
would be a component level concept.
> Also, I think we should have a default runlevel attribute on
> composites as well that applies to all children. This may be
> implicit in the above since composites are just components.
I was thinking order applied within a composite to the components of
a composite (either direct children or ones from include's). You
could specify an initLevel on a component implemented by a composite
but that would determine the order in which the sub-composite as a
whole was started; any order applied to components in the sub-
composite would be independent of the order of those in the parent.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component start order
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 14, 2006, at 12:43 PM, Jeremy Boynes wrote:
> The Java implementation model allows components to designate that
> they are "eager" init which means that they will be initialized
> when the composite they are in is started rather than on first use.
>
> One problem that I ran into with the extension stuff is that the
> specification does not say or even allow a user to say in which
> order the components will be started.
>
> One option would be to follow a lexical convention and say that
> components will be started in the order that they appear in the
> SCDL. I have a few reservations about this:
> * users may have other criteria for laying out the file (for
> example grouping components together)
> * this can be confusing in the presence of include elements - users
> may want to group
> components together in an include that would fit in different
> places in the start order
>
This can also be dangerous if a tool doesn't preserve the exact order
or someone inadvertently changes something.
> Instead I'd like to propose we support an init-level indicator like
> the run level from Unix systems. Components would be started in
> ascending order of the init level they provided.
>
> This could be done as an attribute on the <component> element,
> something like:
>
> <component name="start2nd" initLevel="20"> ...
> <component name="start1st" initLevel="10"> ...
>
> This would also allow us to eagerly initialize components without
> having to use an @Init annotation.
>
I'm wondering if specifying the start level in SCDL is crossing
semantics with eager init...
As background, one thing I was planning on proposing to the spec was
moving eager init off of @Init and onto @Scope for couple of reasons.
First, eagerness is associated with the scope, not an initializer
callback, IMO. The second reason is that it avoids a problem I've
been noticing lately where I want to eager init something but I don't
need an initializer callback, and I am forced to add an empty method
just to get the component to be instantiated eagerly. Couple that
with constructor-based injection, and I think it is better to but
things on @Scope.
What if we said eager init is a component type concept and is true or
false (specified on @Scope)? Then, run level is the SCDL
configuration of eager init. So, a component would be eager
initialized based on the component type info and would be done so in
the order specified by the SCDL runlevel attribute. If no runlevel
attribute were present, we would default it to some level (maybe 100).
Also, I think we should have a default runlevel attribute on
composites as well that applies to all children. This may be implicit
in the above since composites are just components.
Jim
> Seem reasonable?
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org