I have Spring MVC project (gradle, kotlin) and Idea inspection shows me my MVC controller methods as unused.
How can I make the inspection tool recognize that those methods are entry points and should not be analyzed for usages?
You can mark the spring mvc annotations such as #PostMapping, #GetMapping etc as entrypoint annotations in the idea inspection profile
Related
I am developing a Maven plugin which generates some application metadata related to Spring Controllers. Currently I am unable to get the "Controller" annotation (with its "value" property) of my spring controllers so I am kinda stuck...
How could I get this annotation and its value ?. Thankx
This code let me get the desired values. Thankx to all
I'm just learning asp.net mvc and I'm trying to figure out how to move my controllers into a separate project. Typically when I have designed asp.net web apps before, I created one project for my models, another for my logic, and then there was the web.
Now that I'm learning asp.net mvc I was hoping to follow a similar pattern and put the models and controllers each into their own separate projects, and just leave the views/scripts/css in the web. The models part was easy, but what I don't understand is how to make my controllers in a separate project be "found". Also, I would like to know if this is advisable. Thanks!
First of all, it is certainly a good idea to put your model into a separate project. As you've discovered, this is trivial.
Regarding Controllers and Views, I don't see any obvious advantage to separating them for most basic projects, although you may have a particular need to do so in a particular application.
If you do choose to do this, then you will need to tell the framework how to find your controllers. The basic way to do this is by supplying your own ControllerFactory. You can take a look at the source code for the DefaultControllerFactory to get an idea for how this is done. Subtyping this class and overriding the GetControllerType(string controllerName) method may be enough to accomplish what you're asking.
Once you've created your own custom ControllerFactory, you add the following line to Application_Start in global.asax to tell the framework where to find it:
ControllerBuilder.Current.SetControllerFactory(new MyControllerFactory());
Update: Read this post and the posts it links to for more info. See also Phil Haack's comment on that post about:
ControllerBuilder.Current.DefaultNamespaces.Add(
"ExternalAssembly.Controllers");
...which is not a complete solution, but possibly good enough for simple cases.
While it is reasonable to create your own ControllerFactory, I found it more convenient to define all my Controllers in each project, but derive them from Controllers in my Shared project:
namespace MyProject1.Controllers
{
public class MyController : MySharedProject.Controllers.MyController
{
// nothing much to do here...
}
}
namespace MySharedProject.Controllers
{
public abstract class MyController : System.Web.Mvc.Controller
{
// all (or most) of my controller logic here...
}
}
This has the added benefit that you have a place to put your Controller logic that differs from project to project. Also, it is easier for other developers to quickly find your Controller logic because the Controllers exist in the standard place.
Regarding whether this is advisable, I think it absolutely is. I've created some common Account Management logic that I want to share between projects that otherwise have very different business logic. So I'm sharing my Account and Admin Controllers, but the other Controllers are specific to their respective projects.
Add the Class Library for your mvc project.
In the class add the following code(For u'r Controller Code)
namespace ContactController
{
public class ContactController : Controller
{
public ActionResult Call()
{
ViewBag.Title = "Inside MyFirst Controller.";
return View();
}
}
}
On the mvc project view folder add the folder for Contact and create a Call.cshtml file.
Add the class library project reference into your main MVC project.
Finally to refer contact controller namespace into Route Config.
My problem solved after I updated System.Web.Mvc NuGet reference so MvcWebsite and Class Library use same System.Web.Mvc version
No need to add default namespaces
The simplest form of separation I use is to retain the Views "as is" in the original MVC project but remove the Controllers. Then in a new ClassLibrary project add the Controller classes and ensure they inherit from Controller.
The MVC routing engine will automatically route to the Controllers in the ClassLibrary and the Controllers will automatically construct the Views from the original MVC project, provided you have your references and usings correctly in place.
I am using this architecture to implement an Html Reports module that can be compiled and deployed separately from the main solution. At last I am free from SSRS!
I am working one POC where I want to create plugin based web application. Main application will have all the spring mvc context. Plugins can write spring controllers but they cannot have their own spring context file. What I want is when plugin is installed all its controller is scanned (plugins controller need to be in specific package so for that package component scan will be defined in parent context) and ready to use. I am able achieve the installation part however when I am trying to access bundle/plugin controller end point through rest call I get no mapping found error.
Has anyone tried something like this? It will be great if I can get reference to some example.
Thanks!!!
If you remove the spring part, I've already done this with
a) Apache Wicket and Pax Wicket
b) Vaadin
For a) you might want to look at the Apache Karaf WebConsole.
For b) take a look at this rather "old" showcase of mine.
Both of those showcases use either standard OSGi services or Blueprint for the services (http-services) and the discovery of new "web-components" or views.
We have encountered a problem using Spring Portlet MVC 3.1 when using multiple controller classes and the DefaultAnnotationHandlerMapping.
Background
We are using Spring Portlet MVC 3.1 with annotations for the Render & Action phases
We are using JBoss EPP 5.1.1
Issue
For a Portlet render request with params, an incorrect page is rendered in the portlet
Cause
Spring Portlet MVC is using a different method for #RenderMapping than the expected method with the correct annotations
Technical Analysis
All our controllers contain #RenderMapping and #ActionMapping annotations, and all have “params” arguments to ensure that the expected method is invoked based on a parameter set in our portlet URLs. For default rendering, we have a method that has a #RenderMapping annotation with no “params” argument, which we use to render a blank JSP when the request contains no parameters.
Based on the reading of Chapter 7 and 8 in your book, we learnt that the Dispatcher Portlet tries to get the appropriate handler mapping for the incoming request and send it to the appropriate method in the controller bean configured. Our assumption was that our default #RenderMapping annotation (with no params) would only be invoked after it has checked that there are no other methods in the Controllers with an annotation that matches the specific request parameters.
However, we have debugged to realise that this assumption is incorrect. The DefaultAnnotationHandlerMapping appears to traverse through the available list of annotations in the Controller beans in some pre-defined order. This means that if the controller bean with the default #RenderMapping annotation (with no params)appears before in the list, the method with the default #RenderMapping annotation (with no params) will be invoked rather than the correct which is further down the list.
Manifested Error
We are developing in a Windows environment and deploying to a Linux environment. In Windows we see that the handler cycles through the controller beans in alphabetical order, so we initially solved our problem by adding the #RenderMapping annotated method with no params in the controller with the bean name closest to ‘Z’.
In Linux, however, it appears that the controller beans are detected in a different order. I have attached the Spring logs below to highlight the issue. The no params #RenderMapping annotation is in the YourDetailsController, and as you can see in the Windows log it appears last in the list, whereas in Linux it doesn’t. This means that if we try to access one of the controllers that appears after the YourDetailsController in the list we instead always end up hitting the no params annotation in the YourDetailsController instead.
Questions
Is our assumption incorrect?
Does our diagnosis reflect expected behaviour? Or is it a bug with Spring Portlet MVC?
Is there a different way to get the annotations scanned to form the handlermapping bean list?
Would using xml configuration (instead of annotations) remove our problem?
Would we able to define multiple handler mapping and order so that the default handler mapping is the last handler mapping used by the dispatcher portlet?
Any thoughts or advice you have on this problem would be greatly appreciated.
Mike. I'm experiencing the exact same problem. I'm using JDK 7, Spring 3.1.1.RELEASE and Hibernate 4.1.3.Final. I'm developing on Linux (Fedora) and deploying on Linux (Fedora and SL).
I was stuck because I was sure the pieces (controllers) were working one at a time but together the call to a render request was randomly ignored. Sometimes changing something would make things work again on a render request but they never worked all together.
As Walter suggested, when I isolated the controller containing only the default render request in its own package, left only the default render request in it (before I had the delete/view requests) and separated the scan of controllers in the portlet's XML configuration in two with the scanning of the default controller after the others, suddenly everything works like a charm.
It would be interesting to see if this bug is in the Spring tracker...
I'd been bitten by this problem recently, so thought I'd add some additional information based on what I found.
In my case, my default controller (with empty #Controller and #ActionMapping annotations) was always getting invoked, even though there were more specifically annotated controllers/actions (such as #Controller(XXXX) or #ActionMapping(YYYY)). What made my case weirder was that it worked OK in Tomcat/Pluto, but not in WAS/WebSphere Portal Server.
As it turns out, there is a bug introduced in 3.1.x of Spring that means the annotation handlers aren't sorted properly. See https://jira.springsource.org/browse/SPR-9303 and https://jira.springsource.org/browse/SPR-9605. Apparently, this is fixed in 3.1.3.
The big mystery to me was why it was working in Tomcat but not WebSphere? The underlying cause is that Pluto (2.0.3) uses Sun JRE 1.6.0 whereas WebSphere uses IBM JRE 1.5.0. The two JREs have a different implementation of Collections.sort() that results in a different output order when ordering array elements that are reporting they are equal (that is, the result of the compareTo() function). Because of the above Spring bug (which reports some handlers as being equal when it shouldn't) it means that the ordering of the handlers was non-deterministic across the two JREs.
So, in my case, the IBM JRE just happened to put the default controller as the very first element, and so it would be picked up every time. One way that we can affect the ordering of "equal" handlers (where "equal" is a dodgy definition due to the Spring bug) is to change the order that they are found by Spring - which affects the order of the input into the sort routine. That is why, per the above posts, moving the controller from the component scan to being explicitly listed in the XML config works. In my case, it was sufficient to make my default controller's package the last entry in my component scan. I didn't need to move it to the XML config.
Anyway, hope this helps shed a little more light on what is happening.
Response received from Ashish Sarin:
Hi Mike,
Though I haven't tested the exact same scenario that you are following
in your project, but I can say that it doesn't look like the right
approach to define your controllers. If your controllers only make use
of #RenderMapping and #ActionMapping annotations, then it might be
difficult for the developers to find out the exact controller
responsible for handling an incoming portlet request. I would
recommend that you make use of #RequestMapping at the type-level to
map portlet request to a particular controller, and use request
parameters to further narrow down the request to a particular method
in the controller.
Let me know if you still face any issue with this approach.
Mike, Your description is exactly the same issue we are running into. In Windows, we implemented the same workaround (prefixed the controller with the default rendering with a Z) and that solved it. That same code in a Linux environment has the same issues as yours. It looked like it was a times stamp issue ordering as the methods that weren't getting picked, but no luck going that route.
I assumed this was a spring bug.
I think the approach here is ok - we want different controllers handling different functions, but we want a default controller.
I just found one workaround for now. I moved the controller with the default rendering method to a different package so it is not included in the component-scan.
I add that controller manually (in the portletname-portlet.xml file) after the component-scan line, so it adds that as the last controller.
We use context:component-scan (in nnn-portlet.xml) to divide controllers default render mappings between portlet.
I'm integrating a series of controllers into an existing project which already contain controllers which use Castle Windsor for DI/IoC. I've modified the Installer to only register Controllers in a certain namespace (specifically the root). This modification appears to be working. When I try to access my controllers, which do not use Castle Windsor and are located in a different namespace (specifically, a custom Area), I get the error message: "No component for supporting the service [Controller Name] was found".
Is it possible to mix "traditional" controllers with controllers which use Castle Windsor in a single project?
Does this make sense?
If you are getting that error, you are trying to resolve the controller (directly or indirectly) through the container.
If you have a separate logic path that needs a controller that isn't register from the container, nothing is stopping you from calling new MyController().
As an aside, thinking in terms of the controller using the container is somewhat backwards. The container manages your instances--your instances have no idea whether they are container-managed or not.