I'm trying to migrate a big web app from Spring 2.5 to Spring 4. The whole context and MVCs are being configured using XML files, not annotated. Does anybody know if it's possible to declare argument resolvers to MVC beans injected using XML files? When using annotated controllers, the solution is to inject argument resolvers:
<mvc:annotation-driven>
<mvc:argument-resolvers>
<bean class="com.company.CustomResolver" />
</mvc:argument-resolvers>
</mvc:annotation-driven>
But I can't implement this solution because, due to size and legacy reasons, I can't migrate the app whole set of MVCs to annotated controllers.
Related
I'm very newbie with ASP.NET, but not with Spring (Java).
I was wondering how the ASP.NET Core applications are normally configured ? The place I used before for my config in a web applications was application.properties (or others under /src/main/resources cause I used allways maven) and later I just had to add #Configuration Bean referencing the attributes in the POJO.
So is there a similiar way to do config stuff onLoad time on ASP.NET ? (easily)
How do you normally configure a ASP.NET or Where do you put the configuration files ?
How is the right way to do it ? Do you normally have a schema of files and directories to follow ?
Try this:
Class
using System.Configuration;
private string varName = ConfigurationManager.AppSettings["key"];
Web.config
<appSettings>
<add key="key" value="vaue" />
</appSettings>
Bit of a late answer here, but the approach in ASP.NET Core is to use .NET Configuration abstractions, including IOptions which is detailed on the same page. There are providers for application.json, environment variables and a variety of other options.
Coming from Spring, you may also be interested in config providers offered by Steeltoe, probably most notably options for using Spring Cloud Config Server
Spring boot stores in template files in /src/main/resources
Where is this configured and how can I get Spring MVC to do this when not using Spring Boot?
In Spring Boot templating is usually configured via autoconfiguration, which takes information from application properties. For instance Thymeleaf template location can be configured like this:
spring.thymeleaf.prefix=classpath:/templates/ # Prefix that gets prepended to view names when building a URL.
See Spring Boot properties reference for more details.
Without using Spring Boot you can configure the same behavior by specifying custom ViewResolver bean and specifying prefix for templates. You can take a look at ThymeleafAutoConfiguration for inspiration.
Same principles apply to using other templating engines than Thymeleaf with Spring MVC.
I am developing a web application based on Spring MVC framework. In this application I need to persist some data to DB.
I intend to use Spring data JPA as well. Now where is the best place to have the Datasource configured? I intend to deploy this in Apache tomcat.
I guess we have two places:
1) Define in the spring configuration file, like below:
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.h2.Driver"/>
<property name="url" value="jdbc:h2:tcp://localhost:9092/~/test"/>
<property name="username" value="sa"/>
<property name="password" value=""/>
</bean>
OR
2) Define in the Tomcat.
Is my understanding correct? Are there any difference in approaches in #1 and #2?
If we use #2, can Spring do dependency injection to the Datasource when needed by the application? OR can we reference the Datasource by JNDI lookup in this scenario?
I am learning this of my own, to understand how real life applications work; so any deeper insight would be of great help.
I have personally gone back and forwards between setting the datasource as JNDI and defining it in the configuration.
I came to the conclusion that I prefer defining the datasource in the configuration for a couple of reasons:
Using JNDI I would need to add the mysql-connector jar to the tomcat lib. And I don't like to have to change the running environment to cater for a specific app.
Doing the configuration in the web application, I can use annotation to configure, and no XML
I think is correct to say that is the application that needs to know how to connect to the database, not necessarily the container
I have web app which is already developed based on Spring MVC. I need to re-implement that web app in Mule.
Can I develop the mule application based on Spring MVC?
Can I declare the Spring MVC dispatcher servlet inside a mule's servlet endpoint and take things further from there?
The web app has web.xml where it defines the DispatcherServlet, the contextparams, the listener classes and so on. How can we remodel that in a mule application?
Any examples where a mule application is developed based on SpringMVC would be great.
Thanks to its embedded Jetty container, you can deploy any JavaEE web application in Mule. So there's no need to remodel anything.
The "Boosktore" example application demonstrates running web-apps within Mule: https://github.com/mulesoft/mule/tree/mule-3.x/examples/bookstore
Mule ESB is not an MVC Framework. It is developed using enterprise integration patterns in mind.
Please go through this blog, to know when to use ESB.
spring mvc can be integrated with mule.
Define all your spring related configuration in separate xml file and include it in mule configuration file.
You can write your custom transformers ,in the custom transformations you can inject or do an autowire of your service classes and from service object you can interact with dao layers.
I have a web app that depends on multiple internal maven projects, can one wire components from other projects via component scan ?
For example :
in the application context xml of the web app project
<context:component-scan base-package="com.mycompany.app" />
<context:component-scan base-package="com.mycompany.projectX.service.impl"/>
<context:component-scan base-package="com.mycompany.projectY.service.impl" />
Yes, and that is how you do it. However, if there is an ambiguity, you might get into trouble. For example, there are several implementations of the same interface that you want to wire.