I have a spring boot project. I have a form where I bind an entity property using its id(Long). Like so,
<input name="entityProperty" value="1" ... />
It binds successfully when submitted (there's already an existing entity with id=1).
However, I export this project via jar file and use it in another Spring MVC project (not Spring boot). Now, I'm getting an error when binding this same scenario: backingObject.entityProperty is null.
It's similar to this question. It's suggested there that I have to create a conversion service, from Long to Type of my entity.
Do I have to do that solution also? Why didn't I have to provide that in my spring boot project? What's the default configuration for spring boot?
I fix this by adding a custom property editor,
public class BaseEntityEditor extends PropertyEditorSupport {}
However, it is still unclear to me why it works by default in my Spring Boot application.
Related
I have a common project I'd like to import to both a spring boot application and a J2EE application. One of the Objects is a set of attributes set from parameters. In spring boot I'd like to use #Value to set them, for the non-spring platform I have to load the properties with code. I'd like to use the same object for both environments since it's use is pervasive. My attempts to use builders have failed because they inevitably get instantiated before the spring objects.
Who's done this?
Thanks in advance
I'd hoped for something more elegant but maybe I'm spoiled by Spring Boot. I had to replace the #Autowired parameters class with a builder that implements ApplicationContextAware. The setApplicationContext method will instantiate the parameters object if it gets executed (the builder class was loaded by Spring and is aware) or by the simple retrieval of parameters for a non-spring environment.
I understand how SpringBoot saves time in other respects such as having an embedded server and starter dependencies, but how does SpringBoot reduce boiler plate code needed for an application?
Thanks
Spring Boot brings a ton of autoconfiguration classes, which create beans with default configurations, that would have been created by the developer themselves previously. An example would be beans for database access. You would have created a datasource, maybe a JdbcTemplate, connection pool etc. Now those beans are created with autoconfiguration (example: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jdbc/DataSourceAutoConfiguration.java), and configuration can be customized through application.properties files.
Spring boot comes with starters and through maven you can search for the required dependency and add it to your project it supports rapid development and below are some key features of spring boot
Removes boilerplate code of application setup by having embedded web
server(Tomcat) and in memory db.
Auto configuration of application context.
Automatic servlet mappings.
Embedded database support(h2)
Automatic controller mapping
You can look at Spring Boot as an opinionated distribution of Spring. It comes with sane defaults and machanisms to hide the boilerplate while still making changes to those defaults possible.
When you use annotations #SpringBootApplication, Spring boot takes care of creating all the beans required for running WebServer and injecting it using its Dependency Injection feature.
#SpringBootApplication is alone equivalent to below three annotations.
#Configuration : You can define your own configuration class to register your beans in application context.
2.#EnableAutoConfiguration : Spring automatically creates beans available on your classs path using this feature.More details are available here.
#ComponentScan : Scans the current and base package where your application class lies.
It Creates ApplicationContext which contains all the necessary beans, ServletWebServerApplicationContext is one such bean created which takes care of initializing and running a WebServer by looking for ServletWebServerFactory bean(provides the webServer) within the ApplicationContext.
There is lot more going on behind the scene. Here is a video which explains it in details.
https://youtu.be/uCE3x4-GQ0k
https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/web/servlet/context/ServletWebServerApplicationContext.html
What's the best method to initiate a new Spring Project ?
Initiating Spring project is a lot of pain with various xml and db configuration.
Is there an "official" repository with complete sample project, as MVC with db access and so ?
Spring Boot may also be the solution, but some point still not clear to me :
How to add external components (such as Quartz) without creating some xml config ? (No such xml in Boot apparently)
Is a Spring Boot builded app is production-proof ?
As writen in the comments http://start.spring.io/ is the best way to start Spring boot project(STS has integration for it).
If you want to use something that is not supported by Spring Boot you can init spring beans the same way you do it in xml, just use java configuration. See this for example: http://www.tutorialspoint.com/spring/spring_java_based_configuration.htm
Also useing xml is still available. You can add #ImportResource on your Configuration class
#EnableAutoConfiguration
#Configuration
#ImportResource({"classpath*:applicationContext.xml"})
In Spring, I'd like to do the following:
<import resource="${resourceFile}" />
However, 'resourceFile' is not evaluated by the import.
The reason why I need it to work is I defined to two different resourceFiles:
resources-serviceA.xml
resources-serviceB.xml
Each of the above files define different sets of beans. When running ServiceA, I wouldn't need the beans needed just for ServiceB and hence I do not want to create them.
Any pointers on how to accomplish this?
We are using Spring 3.0.
Spring 3.0 can not evaluate properties inside import tag, evaluating those was one of the new features of Spring 3.1 (in 2011)
See Spring 3.1 M1: Unified Property Management
So basically you should use the actual version of Spring. Spring 3.1+ also introduced bean profiles, so you can define ServiceA and ServiceB in different profiles.
If you are interested how this problem was solved by users of Spring 3.0 you can look at Import Spring config file based on property in .properties file but keep in mind that Spring 3.0 is 3 years old now, it's suspicious to make changes in the basic bootstrapping configuration of the 3yo project, consider switching to Spring 4.0+.
We have a fairly involved web application written using spring-mvc with a maven build system and would like to harness all the power of Grails for the front end.
So the Grails app will essentially call into the spring-mvc app's service layer to access its business logic and data.
I need some guidance with my architectural approach to this integration at a high level.
From my understanding, I will need to;
- add my spring-mvc app as a compile dependency in my BuildConfig.groovy.
- Expose the service layer objects as service beans in my conf/spring/resources.groovy and inject them into my controllers
Questions:
My spring-mvc app has lots of dependencies of its own (which it obviously has to have) which are causing lots of dependency errors. Should I be setting "transitive=false" in my config and calling all of these in my Grails app?
How should the datasource get configured? I guess I have to integrate the applicationContext of my spring-mvc app by calling it from my Grails applicationContext and hope it all bootstraps nicely?
So the Grails app will essentially call into the spring-mvc app's service layer to access its business logic and data
Can you be a bit more specific about which components of the Spring MVC you want to use from Grails, is it just the services and datasource?
I will need to add my spring-mvc app as a compile dependency in my BuildConfig.groovy
yes
Expose the service layer objects as service beans in my conf/spring/resources.groovy
Although you could make the Spring beans known to your Grails app by defining them individually in resources.groovy, this is unnecessary because you've already defined them in an Spring XML file (presumably) in the Spring MVC project.
Instead you can use the importBeans method of the BeanBuilder to import the Spring beans defined in this XML file into the Grails app. Once you've added the Spring MVC project as a dependency of your Grails app, the Spring XML file should be on your classpath, so all you need to do is add the following to resources.groovy
beans = {
importBeans('classpath:/path/to/file/applicationContext-services.xml')
}
How should the datasource get configured?
A Spring bean named dataSource defines the datasource that a Grails app uses. In a standard Grails app, this bean is created based on the configuration in DataSource.groovy. If your Spring MVC app defines a bean with this name, then this should be used instead after making the changes above. To be sure that Grails is using the datasource from your Spring MVC app rather than whatever is in DataSource.groovy, I guess you could delete the contents of the latter.