A idea I have is to have something like a filter on @Provides.
So if you have multiple interfaces, you can specify when that interface
is valid.
@ProvidesWithFilters({
@ProvidesFilter(provides=UsesServices.class,
filter="(configGood=true)"),
@ProvidesFilter(provides=OffersServices.class,
filter="(available=true)")})
or even use an enum based run level.
@ProvidesWithFilters({
@ProvidesWhen(provides=UsesServices.class,
filter="(state>=CONFIGURED)"),
@ProvidesWhen(provides=OffersServices.class,
filter="(state>=READY)")},
@ProvidesWhen(provides=MonitoringServices.class,
filter="(state=BUSY)")})
enum State {
INVALID,
CONFIGURED,
READY,
BUSY
}
The >= for enums would compare ordinal values.
-----Original Message-----
From: Clement Escoffier [mailto:[email protected]]
Sent: 17 February 2010 11:33
To: [email protected]
Subject: Re: How do I have a component which is not immediately valid?
Hi,
On 17.02.2010, at 10:49, peter lawrey wrote:
> Hello Clement,
> Thank you, this works exactly as we want it to. We may use this
> approach instead of using a @Controller in some cases.
Great,
We're considering to introduce a 'scope' attribute to the @Controller
annotation to define the impact of the changes. For example,
scope=service will keep the instance valid but block the service
registration. That might also do what you want. But, right now it's just
an idea :-)
Regards,
Clement
>
> Regards,
> Peter.
>
> -----Original Message-----
> From: Clement Escoffier [mailto:[email protected]]
> Sent: 12 February 2010 10:03
> To: [email protected]
> Subject: Re: How do I have a component which is not immediately valid?
>
> Hi,
>
>
> On 12.02.2010, at 10:49, peter lawrey wrote:
>
>> Hello Clement,
>> That sounds like a great idea. I haven't had much luck getting the
>> filters to work. Can you point me to some working examples using
>> annotations?
>
> The idea is just to add an LDAP filter to the require annotation like
> @Requires(filter="(connected=true)")
> private Service myService;
>
> On the others side the provider define the service property:
> @Component
> @Provides
> public class MyServiceImpl implements Service {
>
> @ServiceProperty(value="false")
> private boolean connected;
>
> // Callback called when the device is connected ...
> private void onConnection() {
> connected = true; // This will update the connected service
property
> to true
> }
> }
>
> Regards,
>
> Clement
>
>>
>> Thank you,
>> Peter.
>>
>> -----Original Message-----
>> From: Clement Escoffier [mailto:[email protected]]
>> Sent: 11 February 2010 20:01
>> To: [email protected]
>> Subject: Re: How do I have a component which is not immediately
valid?
>>
>>
>> On 11.02.2010, at 10:07, peter lawrey wrote:
>>
>>> I have been setting the @Controller valid to false in my @Updated
>>> method. However, it appears that this is too late to prevent the
>>> Component appearing in the @Requires of other components.
>>
>> Right,
>>
>> Unfortunately, there is no way to initialize that controller before.
> You
>> can simply add a property to the service (that you set to a different
>> value) and add a filter in your requirements.
>>
>>
>> Regards,
>>
>> Clement
>>
>>>
>>> -----Original Message-----
>>> From: Clement Escoffier [mailto:[email protected]]
>>> Sent: 10 February 2010 18:07
>>> To: [email protected]
>>> Subject: Re: How do I have a component which is not immediately
> valid?
>>>
>>> Hi,
>>>
>>>
>>> On 10.02.2010, at 18:15, peter lawrey wrote:
>>>
>>>> I have a component which I don't want to be valid until I have
>>> connected
>>>> to a server (at which point the component can be used)
>>>>
>>>> However, the problem I have is that my iPOJO component starts valid
>>> and
>>>> I have to set it to invalid. Unfortunately this results in the
>>>> component being available to other components.
>>>>
>>>> Can I have an iPOJO which starts invalid?
>>>
>>>
>>> You can use the lifecycle controller (@Controller annotation) to
>> impact
>>> the instance lifecycle.
>>> By setting this field to false, you invalid the instance. However,
>>> setting it to true, will not necessary set it to valid, as it also
>>> depends on the others handlers attached to the instance (an instance
>> is
>>> valid is all the attached handler are valid).
>>>
>>> Be sure to set the field value, so create an immediate instance.
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Hampel, Michael [mailto:[email protected]]
>>>> Sent: 10 February 2010 15:32
>>>> To: [email protected]
>>>> Subject: bindex or obr problem?
>>>>
>>>> Hello,
>>>>
>>>> we have the following problem starting a bundle with obr:
>>>>
>>>> In the bundle's manifest we have a header entry:
>>>> Bundle-RequiredExecutionEnvironment: OSGi/Minimum-1.0
>>>>
>>>> bindex is generating this xml entry (within the <resource>
element):
>>>> <require extend='false' filter='(|(ee=OSGi/Minimum-1.0))'
>>>> multiple='false' name='ee' optional='false'>
>>>> Execution Environment (|(ee=OSGi/Minimum-1.0))
>>>> </require>
>>>>
>>>> When we try to start the bundle with obr we get the following
>>> exception:
>>>> filter expression(missing package): (|(ee=OSGi/Minimum-1.0))
>>>>
>>>> unresolved bundle: our.bundle
>>>>
>>>> So it looks like that the ExecutionEnvironment Header is
>>> misinterpreted
>>>> as a package dependency - either by bindex or by OBR?
>>>>
>>>> Maybe somebody else had this problem before - thanx for any help in
>>>> advance,
>>>>
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
