Hey Neil, Karel,
I want to try to make a POC in pure Apache Felix. I am used to working with
Apache Sling, but I would like to make a pure Apache Felix example as to rule
out anything else.
Is there nothing like the slingstart-maven-plugin for pure Apache Felix? This
so that I can make a self contained maven project that makes a bundle of itself
with the maven-bundle-plugin and then also starts a felix container with some
bundles I specify in a configuration? Or what would be the best approach for
making a sort of "integration test" for this. The dictionaryservice.itest in
examples seems totally out of date (the felix-maven-plugin in the pom.xml
doesn't even exist (anymore), but was exactly what I was looking for I think)
Greets,
Roy
> On 28 Nov 2016, at 23:07, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> Roy,
>
> Using immediate (or not) will have absolutely NO effect on the References in
> your component… except of course that immediacy affects *when* your component
> activates, and you can have different services visible at different times.
>
> These are completely orthogonal aspects of the component. If you are seeing
> an unexpected effect then please describe it in more detail. It’s either a
> bug in SCR or in your component code.
>
> Regards,
> Neil
>
>
>> On 28 Nov 2016, at 20:42, Roy Teeuwen <r...@teeuwen.be> wrote:
>>
>> Hey David,
>>
>> True, I know thats what the immediate=true will do.
>> What I don't understand is that when you don't use the immediate=true and my
>> service does get lazily loaded when it is finally needed, that it doesn't
>> load all it's references that are dynamic and multiple.
>> Seeing as I have been taught to try and avoid the immediate=true when it
>> isn't absolutely necessary, I am trying to see if there are possibilities to
>> remove it and still get all the dynamic references.
>>
>> Greets,
>> Roy
>>> On 28 Nov 2016, at 22:37, David Daniel <david.daniel.1...@gmail.com> wrote:
>>>
>>> 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
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
