Develop Reference

DB configuration for library in Spring Boot

I am using Spring Boot for creating Microservices. I have implemented a common library (jar) where other Microservices uses it for security and validation purposes. I have a requirement to have on common functionality where it requires DB connection.
I have planned to use the same common library to implement, but to supply the DB details, each Microservice using this common library has to configure the DB details in its corresponding application.properties. I wanted to know is this right approach of asking individual microservice to supply DB details in a agreed property names and it can be used by library ?
Another option I think is to implement it as a another Microservice and other Microservices can invoke using RestTemplate. But I don't want to do this as it is a simple functionality.

Why using Apache Camel rest DSL rather than spring boot rest controller?

I just searched many topics of camel, many of them mentioned that Camel provided the rest api support, but I don't know why it provides it ? As it can integrate many frameworks , for example spring, and springmvc/springboot also provide the rest ability.
As a beginner for camel, the first question of mine is just : what's the benifit / adv of apache camel for rest ? why use camel rest route api rather than springboot restcontroller ? At least, you can see that springboot rest controller can provide the restful api with explicit design/implementations, readable annotations and well integrated with spring validation, swagger UI , etc.
Another question from me, if need to use apache camel, can we use spring rest controller for rest api and camel for other parts ? Or it's not suggested to do things in this way ?

Well, Camel is an integration library that can be used in many environments. It can be used standalone, with Spring Framework, in Apache Karaf etc. So this is a first point:
When Camel is used without Spring, it is worth nothing that Spring has excellent REST support.
Camel excels with its more than 200 components. It supports mainly everything (protocols, data formats etc) that is used out there and it abstracts most of the annoying transport level code away from you. You simply use a DSL to build integrations between different types of endpoints.
rest("/orders")
.post()
.to("activemq:queue:myQueue")
This is a 3 line Camel integration that receives REST calls from clients (POST) and sends the received data to a JMS message queue. Here we got the second point:
Even if Spring is available, Camel must provide REST support in the Camel DSL to allow REST integrations with other endpoints
And yes, you can of course use the Spring Framework to build a REST service and then call this REST service from a Camel Route. But what is not possible, is using this Spring REST service as a Consumer of a Camel Route (the 3-line example above).

Burki's response is great. In my opinion, it does worth adding two additional points.
if you like the way Spring lets you implement your service, you can still benefit from both worlds and integrate your #RestController with your Camel Route by using an istance of FluentProducerTemplate.
if you build your service with Camel from the beginning, including the Rest DSL you can take advantage of Camel's error handling implementation (which is very great, imho) from the earliest stages of your application
More often than not, using Camel is not just a matter of having fewer lines of code. Camel brings you the power of a complete lightweight framework, more than 280 components, type and dataformat converters, not to mention EIPs, therefore REST DSL can be considered just as the front door :)

spring boot distributed processing with kafka

I have several apps developed using spring boot. Some apps call another apps, that in time call other apps, it is getting hard to manage and scale. I need to be able to distribute them in a network and also combine the apps in different 'flows' with minimun changes to the apps.
Ideally I would like to wrap the apps and abstract them into components that have N inputs and M outputs. At boot time I would use some configuration to wire the inputs and outputs to real kafka topic queues.
For instance, input A to an app can come from several kafka topic queues, and the output B from the same app can go to other set of kafka topic queues.
I would like to be able to change the queues without having to recompile the apps, also no extra network hops to send/receive from/to multiple queues, this should in the same process and multi threaded.
Does anybody knows if something similar exists already? Can spring integration do this? Apache Camel? Or am I better off writing it myself?

See Spring for Apache Kafka. There is also a spring-integration-kafka extension that sits on top of spring-kafka.
The Spring for Apache Kafka (spring-kafka) project applies core Spring concepts to the development of Kafka-based messaging solutions. It provides a "template" as a high-level abstraction for sending messages. It also provides support for Message-driven POJOs with #KafkaListener annotations and a "listener container". These libraries promote the use of dependency injection and declarative. In all of these cases, you will see similarities to the JMS support in the Spring Framework and RabbitMQ support in Spring AMQP.

spring boot microservice framework how to call another microservice from one microservice

I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?

The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.

If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.

Existing spring application extension by adding camel features

I have my web application written in Spring MVC. It is quite simple app for registering some activities and generating reports after some time. Now I have it done fully in Spring. The only entry point is HTTP webapp request. I'd like to add other entry points to allow user to trigger application via JMS queue, FTP files and SOAP-based web service.
I know I can do this all using Spring own features somehow, but I wonder if it is desirable to involve Apache Camel into all that stuff?
I think about leaving web application as it is (communicating directly with services), only add some Camel magic to spring context and expose several endpoints from Camel and then after messages processing and transformations call existing services.
I think about using Camel to be able to use some asynchronous processing and threads/scalability features. Is it the right way to go?

I will recommend you to use Apache Camel. I have used it for a similar purpose. The solution is an appropriate one from a 'Separation of Concerns' point. Camel implement Enterprise Integration Patters and is a better solution for integrating various protocols and interfaces. Your application should deal with functionality only and as designed should just expose a servlet to get requests and process it.
Handling of interfaces and protocols are well structured in Camel and its easy to maintain and configure in the long run.