I'm investigating a Spring Boot project generated by JHipster and found out that its request mappings aren't done via web.xml nor via Spring's #RequestMapping but like so:
ServletRegistration.Dynamic someServlet =
servletContext.addServlet("someServlet", new SomeServlet());
someServlet.addMapping("/someUrl");
someServlet.setAsyncSupported(true);
My questions are:
Are there any reasonable advantages of dynamic registration instead of classic mapping?
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?
Is there any reasonable advantages of dynamic registration instead of classic mapping?
Dynamic servlet registration Servlet 3+ way of registering servlets. In Servlets 3 you can avoid creating web.xml and configure application in pure Java. It gives you some advantages like compile time check if everything is fine there and what's more important since you do it in Java code, you can do some additional checks or conditions - for example register particular servlet only if environment property is set or class is available on the classpath.
It's not a replacement for #RequestMapping. In case of Spring Boot you will use it most probably when you want to register some 3rd party servlet - like Dropwizard Metrics servlet in case of JHipster.
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
There are at least 2 ways of registering additional servlets in Spring Boot. See answers here: How can I register a secondary servlet with Spring Boot?.
Your own controllers you map as usual with #RequestMapping.
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?
Nope. For setting this header you use usually CORSFilter (read more: Enabling Cross Origin Requests for a RESTful Web Service). asyncSupported flag is used to make servlet able to process request asynchronously.
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 do have a Java web application which has several servlets, I want to turn it into an optional module of a Spring mvc application. Ideally I would like to add the module as a "dependency" to make it available and add the proper link in my primary UI.
Is there a popular way to achieve this?
Many thanks in advance!
Convert all projects to maven projects, then Servlet specific projects are modules specified in the overarching MVC parent project.
That way, at build time, all required Servlet projects are automatically built by maven whenever you build the parent... And you can optionally exclude Servlets at build time.
To convert a normal java servlet project to spring mvc you would need to do the following
1) In your web.xml you would have to specify your dispatcher servlet with and the url pattern for which it would get invoked. Specify the servlet class as the dispatcher servlet class and servlet name as a custom name for this servlet
2) Create an xml file as servletname-servlet.xml
3) Convert your custom servlets to controllers by having them implement the Controller interface and specify then in the xml file created in the second step
4) Define the mapping of these controllers to the requests
5) Define a view resolver for the requests
6) Deploy
These are broadly the steps you would need to perform to convert your servlet project to Spring MVC
Depending on your servlet container(*), you could try to put the small application in its own servlet context on same container: that means that it would be a totally independant web application.
Then you install in main application a special controller mapped to a full hierarchy that would act as a forwarding relay for the secondary application. Something like :
#Autowired
String extContext;
#RequestMapping("/optapt/app1/**")
public void relay(HttpServletRequest req, HttpServletResponse resp) {
ServletContext ext = req.getServletContex().getContext(extContext);
String extUrl = req.getServletPath();
if (req.getPathInfo() != null) {
extUrl += req.getPathInfo();
}
ext.getDispatcher(extUrl).forward(req, resp);
}
That way, provided you have a global proxy that fordibs external clients to access the second application, all security can be managed by the main, and the second will only receive forwarded request from the main.
If for any reason, you have no proxy to hide the servlet container, you will still (but only) have security by obfuscation, since the direct addresses to the secondary application will never be published, provided you consistently only write addresses relative to first application in links and form actions
(*) ServletContext.getContext() may return null for security reasons on some servlet containers.
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!!!
We've got some Pure Servlets (pure Java classes following the Servlet API, no framework) that we'd like to include in a project that relies heavily on the Spring Framework.
What's the best way of including these servlets in the project, when all the new code we're writing is making heavy use of Spring 3 features?
your servlet container can run multiple servlets, spring is just one of them. why not just include your servlets in the web.xml and see if it works? it should work. spring is not that intrusive, yet (but obviously it already intruded the minds of many developers)
If you declare servlets in the web.xml, alongside the Spring front controller, it most certainly will work.
You just have to be careful when you declare which URLs map to the servlets. If you send "/*" to the Spring front controller, none of your requests will reach your other servlets. Be specific about what you need to send to each one.
As you might know, servlets cannot be configured as Spring beans. If your question is about colloborating with spring beans from a servlet, do refer this thread and also this
Spring provides a couple of classes to make this bridging easier.
ServletForwardingController
Spring Controller implementation that
forwards to a named servlet, i.e. the
"servlet-name" in web.xml rather than
a URL path mapping. A target servlet
doesn't even need a "servlet-mapping"
in web.xml in the first place: A
"servlet" declaration is sufficient.
Useful to invoke an existing servlet
via Spring's dispatching
infrastructure, for example to apply
Spring HandlerInterceptors to its
requests.
ServletWrappingController
Spring Controller implementation that
wraps a servlet instance which it
manages internally. Such a wrapped
servlet is not known outside of this
controller; its entire lifecycle is
covered here (in contrast to
ServletForwardingController).
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.