feat: layotto spring-boot

[ZLBer]

What would you like to be added:
I found layotto spring-boot in the community tasks, and want to implement it.
I went to understand the implementation of dapr spring-boot and found that it is more complicated.
When a method is annotated by @Topic (it needs to be annotated by @PostMaping at the same time), the route (maybe a url) of this method will be saved and exposed through /dapr/subscribe. When dapr runtime starts, it will go to dapr/subscribe to pull subscription information, and then subscribe( the code logic in the dapr), when subscription occurs, it will call back the route.

Does layotto spring-boot need to be implemented like this? In a simple way, when the method is annotated by @Topic, just subscribe to this topic in the java-sdk. But but... this puts the code logic in the sdk again!

Why is this needed:

[seeflood]

There was an issue discussing java-sdk and layotto-sdk-springboot,see #206

Does layotto spring-boot need to be implemented like this? In a simple way, when the method is annotated by @Topic, just subscribe to this topic in the java-sdk. But but... this puts the code logic in the sdk again!

The layotto-sdk-springboot can be implemented as a seperate module which imports java-sdk and has a @Topic annotation and some auto-subscription logic in it.
It's ok that we put some logic in layotto-sdk-springboot module as long as we we keep the java-sdk module simple.
The layotto-sdk-springboot can be regarded as a sugar for springboot users :)

[ZLBer]

@seeflood I know, I will do it, then I will put the code logic in thelayotto-spring-boot sdk.

[seeflood]

@ZLBer niu b

[ZLBer]

@seeflood why registerPubSubCallback params only contains pubsubname? not include topic name?

[seeflood]

@ZLBer Users can write different Subscriber callback for different pubsub component ,e.g. RocketMQSubscriber for RocketMQ, ActiveMQSubscriber for ActiveMQ.

For example, RocketMQSubscriber.listTopicAndSubscriptions may have some special logic in it ,while ActiveMQSubscriber.listTopicAndSubscriptions not.
As for the topic field, RocketMQSubscriber.onTopicEvent can dispatch event according to the topic.

If you can't understand it after reading the description above,tell me and I will add an example

[ZLBer]

@seeflood so I'm a little confused, why not provide a method registerCallback(pubsubName, topic, callback)?

[v0y4g3r]

@seeflood so I'm a little confused, why not provide a method registerCallback(pubsubName, topic, callback)?

The Subscriber interface here is actually not the subscriber commonly referenced in messaging systems that subscribes to topics. This subscriber could have been more precisely named as "deliver request dispatcher" that dispatches deliver message requests to pubsub SDKs according to pubsub component name, hence registerPubSubCallback only accepts a pubsubNam argument. It it the concrete pubsub component's stuff to determine which user-defined listener should be invoked according to topic or other metadata in TopicEventRequest.

[seeflood]

@seeflood so I'm a little confused, why not provide a method registerCallback(pubsubName, topic, callback)?

Is @RayneHwang 's explanation enough? He is the author of it.
To my understanding , @RayneHwang 's concern was : some message queues dispatch messages not according to topic,but some other field like eventCode and xxx, so he decided that it should be designed as registerCallback(pubsubName, callback) instead of registerCallback(pubsubName, topic, callback) .

Emmmmmm, for me, both design styles are fine :)

[ZLBer]

@RayneHwang @seeflood I understand, but every user who wants to subscribe to a topic has to implement the distribution logic in his own method. a little bit difficult but not a big problem . I will implement it according to this logic

[seeflood]

You are right.Maybe we can add a defaultSubscriber to make it easier to use?

[ZLBer]

@seeflood can i move this from example to sdk and change it to defaultSubscriber ？

[seeflood]

yes you can

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.