Develop Reference

Apache Camel XML configuration rules and restrictions

I am learning Camel and trying to integrate it with Spring Boot applications. From what I've read there appear to be two main ways to configure the Camel routes (and other related entities): 1) via Java DSL, or 2) via XML DSL. We don't think the Java DSL approach will work for us, as it doesn't seem that it would allow dynamic route definitions. Maybe I'm wrong? If dynamic routing can somehow be done using Java DSL and whatever, I'd like to know about it.
So, I'm focusing on configuring the routes in XML, where we should have a little more flexibility. The idea is that a given application (or service) could be handed a constructed XML route configuration at deploy-time that would specify the details of that service's routing.
The first question I have is how can we indicate to Camel (or Spring Boot and Camel) what/where the configuration file(s) are? Does it expect specific file naming and/or project location, or is it more flexible? Can it be broken into separate files?
By the way, we configure our Spring Boot applications via a combination of Java-based bean configuration and an application.yml file. We don't use XML for Spring Boot configuration.
I've poked around in a number of places on the Camel site (https://camel.apache.org/) but haven't found much information on this subject. The emphasis definitely favors the Java DSL approach.

There is a spring boot example with XML DSL at
https://github.com/apache/camel-spring-boot/tree/master/examples/camel-example-spring-boot-xml
You can use property placeholders in your Camel routes that can be configured via spring boot configuration (eg application.properties etc).
From Camel pov, then XML or Java can be equally dynamic. You can remove/add routes at runtime. But mind that its not always a good thing to do dynamic changes in production, without knowing if the changes works.

How are IoC and DI used in Spring MVC

I’m taking this udemy course all about Spring Hibernate etc. The course started with explaining how Injection of Control and dependency injection works not in a web perspective just like having simple classes or beans, defining beans and their dependencies inside a config xml file or inside the actual class Using java annotation and then a main class where the beans are created. I understood that despite not really seeing the big benefit of using IoC and DI other than separating roles like creating and maintaining objects and adding dependencies the object needs and I guess when the project is bigger this makes it cleaner and easier to follow right?
However what I don’t understand is how IOC and DI ties in a full spring MVC project. Like I understand using the #Controller annotation means it’s like an #Component and you could make it scan the components automatically when it creates beans but like unlike before there isn’t a main class where beans are created and configured rather I have a controller class where I manually create objects and models and pass that back to the views where I can use the values in the model. I don’t see how I use IoC or DI here? Or is it because it’s a simple project and perhaps the objects we created didn’t have many dependencies?Or are a lot of the uses and implementation done internally or automatically?
I am just struggling to a) see why IoC and DI are that important and b) how are they actually used in a Spring MVC project where you don’t have a main class where you do create beans.

A) Create a project, but don't add any dependency (or web-mvc). Then do it yourself then see how much need time to create configure manually. If it is just a simple mvc project, you can do it manually, but if your project increase day by day then a huge configuration file to maintain your project properly. But when you are professional developer, you don't have so much time to configure all those manually. So here is come the solution IoC and DI. Controller or other anotation are configured in build-in jars. You don't have to worried about to create controller or to create bean, just use them when you neer them. It's save your time as well as headache about is it working or not. It's increase your productivity while your are working on a big project.
B) Yes, there is no main class in web project. To run a web project, you need a server. The server first looking for a configuration (In spring, it's web.xml, dispatcher-servlet). If it available then expand the configuration file, if not then throw an error. In that configuration file, explain everything about the web project. What should do, what is not mandatory, what is entry point etc.
So, IoC and DI are very important because to understand how a web project work behind the scene or how all component work together.

IoC is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern.
In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application.
The advantages of this architecture are:
decoupling the execution of a task from its implementation
making it easier to switch between different implementations
greater modularity of a program
greater ease in testing a program by isolating a component or mocking its dependencies and allowing components to communicate through contracts
Inversion of Control can be achieved through various mechanisms such as: Strategy design pattern, Service Locator pattern, Factory pattern, and Dependency Injection (DI).
You can go with Annotation based configuration, where you can define #Configuration class and return the required beans using #Bean annotation.
Also you can use #Component to your POJO class to treat it as Spring bean.

Why is overriding spring bean declared in one config allowed in another config?

I am starting to learn Spring and came across a feature of Spring - overriding spring bean declared in one xml config in another config.
I do not understand where this feature can be useful. It seems illogical because same container will be configured using two different xmls and even when there are two beans with same ID, instead of reporting the ambiguity it is defaulting to the last one.
Is there a practical scenario where this can actually be useful? Is this good practice?

There are reasons why this could be useful for instance
Testing
Developing Component Libraries
Testing
When testing you can choose to override 1 or more beans. For instance a DataSource you probably don't want to test against the production instance of your database. But maybe an in memory one or one specially for testing. For this you can then just override the DataSource bean.
Developing Component Libraries
You can provide a starting configuration for your libraries and let users override certain components or let them implement interfaces. A sample of this is how the different Spring portfolio projects work (Spring Security, Spring Batch) with their default configuration.
Also when overriding beans spring will log this at startup of your application.

What does application context in Spring do?

I asked a question yesterday ( Using Spring in standalone apps ) on how you would use Spring in a standalone application. From that I learned that you only create the application context object once. So now the question is (even though it was partially answered in a comment) what happens when you create the application context?
Does Spring create the beans and wire them together when you say
new ClassPathXmlApplicationContext("some.xml") ?
I am not sure if I understand the boot strapping, and why it is like that.

The idea behind the ApplicationContext in Spring is that in order to properly inject objects where they are needed, some thing needs to be aware of the configuration the user specifies and inject dependencies based on this configuration.
The ApplicationContext is the thing that understands the user's wishes in terms of where and what should be injected (as well as other things such as AOP pointcuts and such) based on the configuration a user provides, either through an xml file or annotations.

Yes it will parse the bean definition file , it will create the beans , give them the dependencies,
The easiest way to debug is to go with the output print statements,
Put the statements in constructor & setter methods and try different possibilities to track the flow

Loading configurations Meta Data

My application needs some meta data configuration to be loaded at server start up. Meta data are annotations and its do-it-once-forget it-and-use kind. So reading annotations and loading the MetaData objects involves lot of reflection hence I want to do it only once.
Is there any way other than using using Singletons ? I saw #Singleton EJBs which may serve the purpose. But I'm using EJB 3.0 hence that support is not available.
Do you see any other approach (efficient and simple) I can use for this purpose ?
To be more clear :
Using annotations on some classes we are building some configuration objects, that'll be used throughout the application. Hence reading the annotations and building the config objects has to be done only once.

I have found solution for the problem.
I have a #PostConstruct annotated method which reads all the configuration meta data and create the objects. And in the EJB deployment descriptor I configure the initial-number of beans in pool as 1 and also maximum number of beans as 1. Hence this would be a singleton and at the same time would be loaded on server startup.