I am looking for any ideas or PoC on how to integrate (specifically configure) Spring MVC and Vaadin (Framework 8) in one web application; preferably as a context hierarchy.
The use case is the Vaadin application as the root context "/" and the Spring MVC application on some other context "/m" (which will be used for server mobile-friendly views).
I have not been able to find any examples, partial or fully, that shows how this is achieved in the configuration (Spring Boot) and I'm constantly running into various problems with invalid context loading, unmapped MVC view references etc. depending on the examples I'm running.
I've looked into this from the perspective of this line in the Vaadin documentation, but have simply not found anything on these topics I can combine to make a solution.
It is possible to map both DispatcherServlet and SpringVaadinServlet to different context paths to use both simultaneously to e.g. support Spring MVC and Vaadin in the same application. If doing so, remember to also map the path “/VAADIN/*” to the Vaadin servlet for serving static resources.
Related
I have a pretty basic vaadin application running. The application is spring-boot backed and I defined some rest API.
I've added OpenAPI documentation using org.springdoc:springdoc-openapi-ui:1.4.4, which worked perfectly before adding vaadin.
After adding the vaadin dependencies as shown in the vaadin spring-boot tutorial, and creating a view (which works), the swagger UI is no longer reachable.
It seems to me that vaadin completely takes over all web requests. Digging deeper, I've found that vaadin registers a new servlet and catches all requests.
I don't find any docs on how to configure this -- I'd expect that one could configure vaadin such that it serves UI from a different path, say /ui or similar.
I've tried to set
vaadin:
url-mapping: "/ui/*"
in my application.yaml -- but this results in blank pages (no errors) for my vaadin views,
and the vaadin servlet does still take over /.
I use spring.boot 2.3.2.RELEASE, vaadin 14.3.1.
The value to override is (note the camelCase instead of the kebab-case):
vaadin:
urlMapping: /ui/*
Using the kebab-case did (does) not work. As expected, this is a bug. See https://github.com/vaadin/spring/issues/637
From the docs at the point of time:
You can set properties for Spring Boot in your application.properties file.
Example: Setting Spring URL mapping in application.properties.
vaadin.urlMapping=/my_mapping/*
By default, URL mapping is /*.
An additional servlet, such as /my_mapping/*, is required to handle the frontend resources for non-root servlets. The servlet can be defined in your application class. See this Application class for a example.
Source: https://vaadin.com/docs/v14/flow/spring/tutorial-spring-configuration.html#using-spring-boot-properties
I am a new user of Spring framework. I am facing some confusion in understanding the difference between core spring framework and spring boot. As far as I understand, Spring boot is a framework which performs the initial setup automatically (like Setting up Maven dependencies and downloading the jar files) and comes with an embedded Tomcat server which makes it ready to deploy in just one click., Whereas, Spring MVC requires manual setup. All the tutorials that I watched for core spring show bean configuration using bean factory which configures the beans using a .XML file. In Spring boot, this bean configuration file is absent. My question is, what is the use of this bean configuration file? I did not find any legitimate use of this file in making a REST service with spring. I didn't see any use of the Application Context, Bean Factory in creating web application. Can someone point out how can bean factory be used in Spring web apps? Is there any fundamental difference between core spring and spring boot other than the additional components?
The Spring application context is essentially the "pool" of beans (service objects, which include controllers, converters, data-access objects, and so on) and related information that define an application; I recommend the reference introduction. In theory, you can get complicated with the context setup and have hierarchical organization and such, but in most real-world cases you just have a single plain context.
Inside this context you need to install all of the beans that provide the logic for your application. There are several possible ways to do this, but the two main ways are by providing XML files with have directives like bean (define an individual bean) or component-scan (automatically search for classes with certain annotations, including #Controller) and by using Java classes annotated with #Configuration, which can use annotations and #Bean methods.
The XML style is generally older, and newer applications mostly use Java configuration, but both provide entries that are collected into the context, and you can use both simultaneously. However, in any application, you have to provide some way of getting the registration started, and you will typically have one "root" XML file or configuration class that then imports other XML files and/or configuration classes. In a legacy web.xml-based application, you specify this in your servlet configuration file.
Spring Boot is, as you said, essentially a collection of ready-to-go configuration classes along with a mechanism for automatically detecting configurations and activating them. Even this requires a configuration root, though! This is the #EnableAutoConfiguration instruction, frequently used through its composite #SpringBootApplication. The application context and configuration mechanisms work normally once Boot finds them and pulls them in. Spring knows where to get started because you give it an explicit instruction to build a context starting with that entry point, usually with SpringApplication.run(MyApplication.class, args).
The embedded-server configuration just happens to be a particular set of configuration that is really useful and comes with one of the Boot starter packages. There's nothing there that you couldn't do in a non-Boot application.
We are starting a new project using Spring MVC, and we would like to move away from annotation-driven request/url mapping. We wish to implement the following use case:
Use Case A
User enters a URL.
The request mapping handler retrieves a list of mappings (e.g. from the DB), and based on this dynamic list of mappings, it calls the relevant controller.
This is because we want to be able to do the following as well:
Use Case B
We want to load a new Controller (perhaps a new reports module) into the web app without having to redeploy or do a server restart.
We will map this new Controller to a URL and persist it somewhere (most likely the DB).
We would like the Controller to be registered in the Spring app context (managed by Spring).
We would then like to use this new Controller in the request mapping.
We've taken an initial look at the different ways we can implement this, but we are unsure of the best architecture/method to go about this route. A couple of questions:
For Use Case A, how do we implement this within the Spring MVC framework (or if it's possible)?
For Use Case B, is there a good framework or way to be able to do dynamically loading and registering of this for web applications? We've taken a cursory look at OSGI but it seems to be advisable for use in non-web applications.
For Use case A :
Instead of DB you can keep the url mappings in a property file and then use property place holder to initialize beans using xml configuration on context up. This way remaining inside the spring framework, you can avoid annotations.
For Use Case B :
Tomcat supports dynamic reloading of classes but that to of only non structural changes in class file. But this has memory leaks as well as it doesnt cleans up old instance of class loader rather it creates a new instance.
Its quite achievable using spring-mvc-router API.
Please check below link
url-action mapping & routing in Spring MVC 3.0
Here the URL can be configured to controller.method using .conf file, but this can be achievable using java configuration, and i haven't tried so far.
Also if xml configuration chosen, then check out the property 'autoReloadEnabled', but its not adviceable for production use.
Hope this helps!!!
I'm using org.springframework.web.servlet.DispatcherServlet and org.springframework.ws.transport.http.MessageDispatcherServlet in the same app but each is loading own application context, I need to load all beans in a single application context.
The application consists of typical layers web>app>dao etc
What I have tried is to use one single spring-root-context.xml by setting it in the contextConfigLocation.
But didn't help, this has been an issue for me for a long time an I would appreciate any help with this.
Any online references would be a great help.
What you need here is the ContextLoaderListener. This is a ServletContextListener which creates a root WebApplicationContext that is shared amongst all servlets in that webapp.
Your DispatcherServlet and MessageDispatcherServlet will still create their own contexts, but each will have the root context as their parent, so they'll both be able to use beans defined in that root context, like DAOs etc. Some beans will have to remain in the servlets own contexts, such as controllers, view resolvers, SOAP endpoints, and so on, but the shared common beans can go in the root.
For an example on how to configure this, see the Spring docs.
I'm developing a web application using Spring MVC 3.0 and looking for a ready-made solution, if any, or a "best practices" reference for a url/action mapping and routing system that can achieve the following:
REST-friendly controller / method name to view mapping. The current mapping implementation translates the request to a view name, which may be problematic when using several parameters and is incompatible with REST urls
A service that accepts the name of a controller, a method and arguments values and renders the URL that's represented by them
Integration with Spring Security that can allow me to check for a given URL whether the current user is allowed to access it, so that I can decide whether or not to render a URL
A menuing system based on the above that can define menues composed of these actions and render them to page
Basically what I need is the ability to define URLs in one centralized place, so that changing a URL (during development; I'm aware of the don't-change-live-urls idea :) ) does not mean looking up and changing that URL in a zillion pages.
Any directions to such an existing solution / tutorial / guide would be great.
Thanjs
This is a feature I really miss in Spring MVC.
That's why I created the springmcv-router project, basically a port of PlayFramework's Router implementation in Spring MVC (HandlerMapping + HandlerAdapter).
I'm heavily using it in several real-world projects and the Router implementation itself is reliable.
Try using Spring Roo. It utilizes many best practices for spring MVC, and it has a scaffolding feature that automatically maintains a menu, jsp's and all the CRUD methods of a controller.
Setting up Spring Security with Roo is as simple as typing "security setup".
Hope this is helpful.