Correct me if I am wrong.  In summary, it means that @EagerInit is useful
only with Composite scope.  And the Java Annotations and API's spec also
mentions @EagerInit with Composite scope only.  Will it be useful to log an
info message when @EagerInit is found in combination with a different scope?

++Vamsi

On Fri, Sep 12, 2008 at 11:29 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
>
>> Hi all,
>>
>> this week I learned the hard way that Component references are not
>> initialized during startup but on the first method call on a Service.
>>
>> I found some flags called "eagerinit" in the code and a matching
>> annotation "@EagerInit". In the SCA specification this annotation is not
>> documented well, but I think that it may be used to annotate a
>> implementation class to perform initialization on startup time.
>> Of course I tested it, but nothing happened.
>> So is my understanding of "@EagerInit" right that this annotation would
>> force a Service to initlaize it's references before a method is called ?
>> And is this annotation supported by Tuscany ?
>>
>>
>> Bye,
>> Daniel
>>
>>  Daniel,
>
> The question is, what are you trying to achieve?
>
> For a default component implementation in Java (ie just write a class to
> implement your service), the assumption is that your service is stateless.
>  This means that each invocation of a service method works like it is the
> first call to your class - with no history.  So an SCA server runtime can in
> principle new up a class instance for every service invocation - and toss it
> away at the end of that method.  So, for this default case @EagerInit is not
> very useful.  The initialization will only occur just before the service
> method invocation.
>
> SCA provides two other lifecycle patterns for Java component
> implementations - termed "scopes" - Conversational scope and Composite
> scope.
>
> Implementations using these scopes have lifetimes longer than a single
> invocation.
>
> Conversational scope implementations have a lifecycle tied to the lifecycle
> of the conversational (stateful) service that they offer.  This starts
> typically when one of the service methods is called and lasts until a method
> marked with @EndsConversation is called (or until the implementation calls
> an API to end the conversation).  Here, the initialization takes place just
> before the first invocation.  @EagerInit does not buy you much here.
>
> Composite scope implementations have a lifecycle related to the Composite
> in which they are configured - typically the lifecycle is from the point
> where the composite is deployed into the runtime until the time when the
> composite gets undeployed. So here is a scope where the lifecycle of the
> implementation is not tied to any service invocations.  Examples of
> implementations needing this lifecycle are any that might have long and
> complex initialization to handle - eg an in-memory database.  Here,
> @EagerInit allows the implementation to do its initialization when the
> component is loaded, reducing any overhead when the first service invocation
> happens.
>
> So, why do you want to get at the component references ahead of time?  Does
> your need fit the composite scope pattern?
>
>
> Yours,  Mike.
>

Reply via email to