A company I am working with is using Camel with the Spring DSL implementation.
The desire is to establish some type of project/folder template structure for other developers to follow when building new routes. Basically, currently, every developer rolls their own project structure and the desire is to establish a more formal structure ...i.e. Folder A contains Bean definitions, Folder B contains connection definitions, Folder C contains Mappings, Folder D contains the Routes, etc.
I have heard that Camel may have some tools that may help along these lines or at least simplify the process of creating a new route ( i.e. Kamelets ) ...I am looking for opinions and recommendations.
Related
I've been working a lot with Symfony recently, and I really like the ability to define routes in a routing.yml file. I was looking into Spring's routing system and I couldn't find any options other than placing routes in annotations on controller methods. Is it possible to accomplish something like this in Spring?
My first thought was creating an abstract controller that grabs the routes from a .yml file, but that seemed a bit hacky.
EDIT:
For some added context, I am looking to build a simple Database API with Spring. After some digging it looks like the routing.yml file is best suited for working with server-rendered pages, which is not what I aim to do with my Spring project.
Symfony and Spring are different framework. You are used to one use and want to use same it in another entirely different system. It will not work. You have to adapt to frameworks.
Spring will scan your project and collect your specific annotation like Controller/Component/Configuration/... and configures itself. Therefore, there is no need predefined project structure, unlike, for example, Laravel. So, you can define this structure if you want. Or every class can be in one package, just not beautiful.
Back to routing. You can configure them by the value of annotations only. This is interpreted at compile time. (Ofc, there are runtime annotations, but I focused parameters of annotation.) So, you can not use configuration from the file because it is already runtime. So, you should use constants or hardcode.
Or, you can use an alternative: Annotate the interfaces, then the controllers will be the implementations.
Alternative #2: If you use Spring with Kotlin, In Kotlin, you can have several classes or interfaces in one file.
I need help in getting clarification for below mentioned points
I have a swagger json. From this I want to generate Model separately by passing java as language. api and invoker clsses by passing spring as language and want to add model jar as dependency. Because I want to use model for different projects commonly. So I want to include a build task to generate model jar every time to get latest models from json. and will issue swagger code gen command with spring as language while trying to create project. Is this correct way of handling. If not can someone let me know best of handling this.
How to handle versioning from swagger.
I am new in using swagger and spring. Please suggest me best to go
I do something similar. I have my models in a separate project which is then a dependency for a bunch of API projects. This is because the APIs sometimes call each other, so need to know about each others objects.
What I do is:
Swagger structure:
In the models project I have a swagger containing just the definitions (empty object as paths)
In the API projects I have a swagger which references the definitions in the models project
Build process
Build the models project first with generateApis = false
Build the APIs with typeMappings and ImportMappings in the config, telling them to take all the models in common from that namespace
I use the maven plugin to run the codegen. I have a pretty hacky bash script that updates the type mappings in the pom when I have added new objects to the models
I am new to spring boot, have come across a situation...
l have 10 different property files based on various logical modules of a monolith application(db.properties,jms.properties, etc) and 7 envs(pre, sit1,sit2,uat1,uat2,prod, dr). The idea of having diffrent property files so that we can use them almost with no change whenever we move to microservice based approach.
One approach says - we use various spring application names
like - spring.application.name=db,jms,a,b .....
In this way we will land up having 10×7 = 70 files under same folde? (In order to make it profile driven) like jms.properties,jms-dev.properties,jms-uat.propetris...... for all various logical modules.
Is there any better approach to host the files using config server?
We have a monolith application and we plan to continue the same for the time being.
I am struggling to build such facility using spring cloud config server...if any one can help
I'm starting writing a Spring/boot Angular 4 application and I have a small question. In the Angular 4 app we create a folder called LocalEvent (or something) which houses the module, controller, service, html template and css file. How would I create a structure for Spring?
I've seen Spring folder examples where everything is divided into /services /controllers. I understand that Java uses packages, so having 10 folders would mean having 10 packages which could get confusing fast. But I would like to hear from a few more experienced developers how they set up their Spring structure.
There is no Spring Boot structure as far as I know. The service and controller packages structure are the way how Java programmers architect their applications following the popular MVC pattern. Next, there is a Maven standard project structure where other Java or JVM based languages build tools follow
I have a Spring Integration project that has several flows (some where between 10-15). I would like to keep my namespace clean since several flows might have similar sounding components (for ex - several flows might have a channel named fileValidatorChannel). I think I have a couple of different options to keep names from colliding with each other:
A. Preface every component name with the flow that it belongs to. For ex - flowAFileValidatorChannel, flowBFileValidatorChannel, etc
B. Create a context hierarchy where every flow is it's own context and every flow inheriting from a master context where all the common beans/sub-flows are.
What's the better approach? Is there are better way to keep my name space clean?
To be honest your problem isn't clear.
Any Spring Integration component is a bean finally. So, their ids are just to distinguish them from other bean.
Let's imaging if you don't have Spring Integration in your application. So, you would worry about some clean naming strategy for all your beans anyway?
From other side consider to use Spring Integration Flow project:
The goal is to support these, and potentially other semantics while providing better encapsulation and configuration options. Configuration is provided via properties and or referenced bean definitions. Each flow is initialized in a child application context. This allows you to configure multiple instances of the same flow differently.