I believe the immediate true separates the lifecycle from the resolution
phase and is similar to starting a singleton.  If there is no immediate
true then the lifecylce is based on when the service is a dependency and
lazily loaded.  If another service depends on your service and is started
then your service will be started as well but when the other service
shutsdown and your service is not longer needed then your service will
shutdown as well without the immediate = true.

On Mon, Nov 28, 2016 at 3:33 PM, Roy Teeuwen <r...@teeuwen.be> wrote:

> Hey Karel,
>
> Sorry to go further than the original question, but seeing as my question
> is related to exactly the same thing, maybe you can help me understand it
> better.
> Using the exact same example as the in the initial post, if I don't put
> immediate=true, it won't bind all of the services get created at startup or
> get added during the runtime. Is there a reason why it has to be immediate
> = true?
>
> I also tried it by using the following notation, and then this it doesn't
> even bind any of services:
>
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
> ReferencePolicy.DYNAMIC)
> private List<StateMachine> stateMachines = new CopyOnWriteArrayList<>();
>
> Greetings,
> Roy
> > On 28 Nov 2016, at 21:39, Karel Haeck <karel.ha...@telenet.be> wrote:
> >
> > Nicolas,
> >
> > the spec does not specify that static references should be injected
> before dynamic,
> > but it does specify that references must be processed in sequence as
> specified in the component xml:
> >
> > "When binding services, the references are processed in the order in
> which they are specified in the
> > component description. That is, target services from the first specified
> reference are bound before
> > services from the next specified reference."
> >
> > In addition the spec specifies how @Reference annotations are ordered:
> >
> > " In the generated Component Description for a component, the references
> must be ordered in ascending
> > lexicographical order (using String.compareTo ) of the reference names."
> >
> > Note that the default name is based on the field or method name. In your
> case get aclService  for the static reference
> > and "" (empty string) for the dynamic reference as spec states that the
> add , bind or set prefix is removed.
> > ( Actually if one uses Java naming conventions the event methods will
> have names starting with an upper case character and precede the field
> references).
> >
> > By specifying e.g.  @Reference( name = "zStateMachine", cardinality =
> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
> > the static reference should be bound first.
> >
> > Note that there is still a potential race condition between the add and
> an activate method if present,
> > or between two concurrent add() executions.
> >
> > regards,
> > Karel
> >
> > On 28/11/2016 12:09, Nicolas Brasey wrote:
> >> Hi,
> >>
> >> I have a bind order issue with a component that has :
> >>
> >> 1) A static reference specified with annotation @Reference on the
> private
> >> field
> >> 2) A dynamic multiple reference specificed with annotation on a method
> >>
> >> The static reference is not bound before the dynamic ones.
> >>
> >> The code looks like this:
> >>
> >> @Component(immediate = true)
> >> public class MyServiceImpl implements MyService {
> >>
> >>     @Reference
> >>     private AclService aclService;
> >>
> >>     @Reference(
> >>             cardinality = ReferenceCardinality.MULTIPLE,
> >>             policy = ReferencePolicy.DYNAMIC
> >>     )
> >>     public void add(StateMachine stateMachine) {
> >>        ....
> >>         ....
> >>     }
> >>
> >>
> >> According to the Declarative Service specifications, the static
> references
> >> should always be injected before the activate method.
> >>
> >>
> >> Does anyone have any idea what might be wrong ?
> >>
> >>
> >> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
> >>
> >>
> >> Thanks for you help!
> >>
> >> Nicolas
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Reply via email to