I am trying exception handling in spring portlet based UI application,
I have used spring globalexception handling using #ControllerAdvice.
It works fine in servlet based application but its not working in portlet application.I have noticed that spring container has not processed #ControllerAdvice in portlet. I tried searching in internet on the same issue but no luck.
Is there any other way to handle exceptions in portlet applications?
Thanks in advance.
The Portlet support in Spring is rapidly declining, with very little code or documentation of such. You'll notice that the DispatcherPortlet auto-registers an instance of AnnotationMethodHandlerExceptionResolver, not the newer ExceptionHandlerExceptionResolver.
Even if you manually define an instance of the latter in your portlet.xml file, it won't get picked up by the DispatcherPortlet because it specifically looks for implementers of the org.springframework.web.portlet.HandlerExceptionResolver, which is a different hierarchy than the org.springframework.web.servlet.HandlerExceptionResolver (of which ExceptionHandlerExceptionResolver is a descendent).
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 have an application with Vaadin 8 and Spring Boot. Currently, I'm in progress of adding authentication to this app. So, I enabled Spring Security and started tinkering with it. Basically, I followed this tutorial: https://vaadin.com/tutorials/securing-your-app-with-spring-security/setting-up-spring-security
The approach, described there, works fine, however, I'm slightly disturbed by the fact that /VAADIN/** path needs to be publicly available (otherwise, Vaadin doesn't work). I mean, of course, I have protected particular pages by their paths (e.g. /admin) and unauthenticated users won't be able to open them, but isn't exposure of /VAADIN/** path dangerous? What if some hijacker tries to send some request to the Vaadin servlet outside of the UI (by simply curling it) with some specific headers/parameters? Is it possible that by formatting such request in some malicious way, the data will be actually returned to this hacker, bypassing Spring Security?
but isn't exposure of /VAADIN/** path dangerous
It is not dangerous per ce. The framework itself has just some generic parts there, like static resources for the client, like the widgetset and theme. Having said that, it is of course to be noted it application design. For example you should not put something that includes confidential info in your app as ThemeResource, but use ClassResource instead and things like that.
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.
I am new to Spring portlet i am unable to run a sample spring portlet project.. I am trying to run the project from eclipse as run on server on jboss server. My questions are 1. How can we run a portlet project. Do i need some kind of portlet container(I have no idea of this container i just know few names like liferay etc)?? I cant find a full documented example any where.. In Spring mvc based on the request mapping i can call that purticular Controller class but in Spring mvc portlet how can we call this controllers( or Portlets). Is it possible to call a portlet directly by an url?? The sample project is deployed without any error but i cant find a way by which i can call or trigger a portlet. Any help would be much appriciated.
thx
nkovi
Yes, you will need to deploy to a portlet container like Liferay etc, or uPortal. Once you have the portlet container up and running, things should hopefully become more obvious.
Regarding your other questions, I strongly suggest you read some documentation - the Spring portlet docs are not too bad although they are a little behind on annotations.
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).