[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.
