Whiteboard can work with more than one provider. In your example you
simply injected an optional mqttprotocolprovider so it is not clear how
you would distinguish them.
One simple appraoch is that you give the desired provider a name. You
then add this name together with the subscription channel to your
service properties.
The mqttprotocolprovider can be made to only accept the listeners that
match its name. You can even code this in a factory configuration style.
So you only have one code for it and can instantiate it several times
with different mqtt connection properties.
Christian
On 14.10.2016 09:15, Daghan ACAY wrote:
Hi Peter,
This looks great. I thought about white board pattern but problem is
this, there is no single mqttProtocolProvider! they are also created
through factory configuration and bind to device through
configuration. Please see the actual configuration used in application
project here.
https://github.com/daghanacay/com.easyiot.application/blob/master/com.easyiot.heatmap.application/configuration/configuration.json
Correct me if i am wrong but Whiteboard pattern assumes there is only
one mqttprotocolprovider. Peter, I still can work with the code that
you have explained but still won't be as clean. I am thinking of using
service tracker may be in the device but then it is not DS. I think it
is an interesting case that might be worthy of you experts time :)
PS: please excuse me if i misunderstand you or i am making this
something more complicated then it should be.
Cheers
Daghan
Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
emails as clean, short chats.
-------- Original Message --------
From: Peter Kriens <peter.kri...@aqute.biz>
Sent: Friday, October 14, 2016 05:58 PM
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Subject: Re: [osgi-dev] DS component life cycle.
@Christian: The MQTT client is optional and dynamic. So the activate
method cannot be used. You need to subscribe/unsubscribe based on the
availability of the mqtt server.
@Daghan:
Divide and conquer! You’re trying to do multiple responsibilities in
one component and that is the antithesis of modularity, also called
lack of cohesion. This is a perfect example of how things could get
simpler by choosing the right decomposition.
The best solution imho is to introduce a second,component. Let the
Device component just be a Device, it should not have to worry about
Mqtt. After all, you could be connected to other event queues. (It
also makes it easier to test.) You made mqtt optional to reflect this.
This is exactly the reason the Whiteboard Pattern was invented!
This would look like:
@Component( property = “subscriptionChannel=” )
public class LT100HDeviceImpl implements Device,
TtnMqttMessageListener {
// remove the mqtt subscription code but
// implement the TtnMqttMessageListener
}
And the whiteboard component. Notice the _ in the _mqtt field. This
ensures it is set before the event method that has a name that will
appear in a sorted list later. (References are sorted by name.) (I
vaguely recall field references are done before bind methods but this
makes it certain.)
@Component(immediate=true)
public class MQTTWhiteboard {
@Reference
TtnMqttProtocol _mqtt;
@Reference( cardinality =
ReferenceCardinality.OPTIONAL, policy = ReferencePolicy.DYNAMIC )
void addMqttListener( TtnMqttMessageListener l,
Map<String,Object> props ) {
String channel = props.get(
“subscriptionChannel” );
if ( channel != null && !channel.isEmpty() ) {
_mqtt. subscribe( channel, l );
}
void removeMqttListener( TtnMqttMessageListener l,
Map<String,Object> props ) {
String channel = props.get(
“subscriptionChannel” );
if ( channel != null && !channel.isEmpty() ) {
_mqtt.unsubscribe( channel );
}
}
You now created a whiteboard service that can also be used by other
Device implementations while significantly reducing the complexity of
your implementation.
This is why after all those years I still love OSGi … you can only do
this when you have dynamic components. As your struggle showed, trying
to manage this is quickly becoming quite complex. Whenever you enter
in such a struggle, think, lack of cohesion is often your problem.
Kind regards,
Peter Kriens
>
> On 14 okt. 2016, at 08:09, Christian Schneider
<ch...@die-schneider.net> wrote:
>
> In your case simply inject the ttnMqttClient in the @Reference and
do the subscribe in @Activate when you get the config and the
unsubscribe in @Deactivate.
>
> Christian
>
> 2016-10-13 23:00 GMT+02:00 Daghan ACAY <daghana...@hotmail.com>:
> Hi all,
>
> I am trying to create a component that is instantiated by
ConfigAdmin and uses multiple references to operate. Basically the
component should instantiate through a factory configuration and use
that configuration to set up its own @Reference s. You can see the
code here:
>
>
https://github.com/daghanacay/com.easyiot.device/blob/master/com.easyiot.LT100H.device.provider/src/com/easyiot/LT100H/device/provider/LT100HDeviceImpl.java
>
> All the mentioned @Reference ed components are instantiated by
configuration as well, so at a given time the @Reference might not be
available but my own component should still work. yet should the
Reference available then it should be injected, basic 0-1 strategy.
>
> Problem I am facing with the current form of the code is that, the
@Reference injection is happening before the @Activate method is
called. This leads to NPE in the @Reference method due to null
configuration. Is it possible to make this code work such that config
is provided to the component before the dependency injection?
>
> I have tried annotating the class fields and set them "volatile". I
even make them a list and use the class fields in the activate method
this time the class fields were null due to 0-1 strategy. so I end up
with annotating the methods.
>
> I might have designed this all wrong, so any help simple or
fundamental is appreciated.
>
> Regards
>
> -Daghan
>
> Sent by MailWise – See your emails as clean, short chats.
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
