> On 14 okt. 2016, at 09:15, Daghan ACAY <daghana...@hotmail.com> 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 > > <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. > The whiteboard pattern does not assume any such thing. The whiteboard pattern only says that it is NOT the Device’s responsibility. For example, the device can list a property on which MQTT queues it should subscribe. The white board can take this into account, for example, you could create a whiteboard component instance for each supported MQTT. Many solutions. The only thing important is that being a device and handling MQTT are very different things. > I think it is an interesting case that might be worthy of you experts time :) > Yes :-) That and a million other things … > PS: please excuse me if i misunderstand you or i am making this something > more complicated then it should be. > First get the architecture right, then solve it without compromising the architecture.
Kind regards,
Peter Kriens
> 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
> >
> > <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
> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de <http://www.liquid-reality.de/>
> >
> > Open Source Architect
> > http://www.talend.com <http://www.talend.com/>
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
