I maintain a system that uses Spring 3.1.2-RELEASE, and this cannot change. I added code to test the JMS endpoints, but it will not run because of missing class org.springframework.messaging.handler.annotation.support.MessageHandlerMethodFactory. I read here that the org.springframework.messaging package is distributed in the spring-messaging artifact. However, this does not appear to exist in Spring 3, only Spring 4 and later. I read here that I must keep versions consistent.
So then where can I get this package for Spring 3.1.2-RELEASE?
You are right, things get messy when you mix Spring versions.
So then where can I get this package for Spring 3.1.2-RELEASE?
Probably not the answer you want to hear, but you may need to find an alternative means of testing. According to the javadoc, MessageHandlerMethodFactory wasn't introduced until Spring 4.1. Looking at the maven repo, the Spring messaging module wansn't available until 4.0.
Related
I started working with spring and I'm using maven.
I want to work with JMX support that spring provides.
I'm trying to include the dependency using maven. And for the same I went to mvnrepository and searched for spring. But I see a lot of projects with different artifact-id and I'm not sure which one should I start using and include as a dependency in my pom.xml.
I expected that I'd find this information here, but I didn't.
Is there a centralized place for spring where I could always go and find what is the artifact-id that I need to choose. I think I'm missing something obvious here.
In short my question is that say if I want to use spring's MBeanExporter is there any formal procedure to know that it is imported via spring-context?
Simply searching for the package name don't work org.springframework.jmx gives me a dependency of spring-jmx. Now I don't know what to use spring-jmx or spring-context
If you're still using spring 2.x then you probably want spring-jmx if you're using spring 3.x, 4.x or 5.x I believe the "org.springframework.jmx" package is provided as part of spring-context. Certainly if you look at the latest javadocs for spring-context(https://www.javadoc.io/doc/org.springframework/spring-context/5.1.3.RELEASE) the "org.springframework.jmx" package is included.
when updating our project from Spring Boot 1.5 to 2.0 the classes EmbeddedServletContainerAutoConfiguration and
ServerPropertiesAutoConfiguration were gone, although we need them desperately. When I search the internet doe those classes, I can't find any replacements for this classes. So my question is: Have those classes been removed with Spring Boot 2.0? If not, where have they been moved to? Or how I can replace them?
Thanks in advance.
EmbeddedServletContainerAutoConfiguration has been renamed to ServletWebServerFactoryAutoConfiguration by this commit during work on restructuring embedded web server packages.
ServerPropertiesAutoConfiguration has been removed by this commit during work on the following issue. Those properties objects are now created using
#EnableConfigurationProperties only.
Note: It might take some time for GitHub to show you particular line number.
I am currently building a library or API which will be used by another Spring REST application, below are the advantages I thought of using Spring.
Spring flow(Context initialization->Post construct)
Easy way of reading properties file
Autowiring and bean management
Rapid development
Below are the disadvantage
Tightly coupled, the main application which is going to use the library/API has to import or refer the configuration class of library in order to initialize context
Main application has to use Spring(considering use in other projects)
Is there anything I am missing, can Spring framework be used to develop API or library?
Note: The number of library to build is 3-5 and will grow in future.
The only reason to use spring you are giving, is to benefit from the building of the application runtime.
I do not see it as a great advantage from spring for a library : it is only replacing a few new and set statements, that could be easily explained in a doc, with even some sample bean declaration for the users of your api, if he wishes to init your lib in a spring context.
One of the drawback you are not giving is the support of multiple versions of spring by your library :
what will happen in one / two years, when an old application developped using your library will need small enhancements, but still be on spring v4, but new application will import spring v6 (with no resource to migrate old app on spring v4 to latest version) ?
So i would use spring in a library only if you need to participate in database transaction of the main application (and other tasks like this where it is really convenient to use spring), but otherwise try to depend as little as possible on spring.
EDIT:
Even when minimising the use of spring in the runtime of your library, you can use it extensively to test your library.
The spring context instead of being included in the resource of your lib is only a test resource, which you can use to bootstrap spring-test, for example.
I have two application. 1 application is old version of spring that is based on xml configuration. There are no annotations used. From This application stored procedures are used for CRUD operations. For Poc I have developed a simple CRUD application using spring boot, I have exposed them a restful services.
Now I have to consume this new rest service in my old application. How to do it? I am looking to use restful template which is not available in spring 2.5.
As you already mentioned, RestTemplate is only available as of spring version 3.0 or later.
So, the basic options I see are:
update your spring version from 2.5.x to at least 3.x
use an external lib offering help in consuming rest services
make up your "own"
If the first is an option, go for it. I can not really comment on the second option, but I'm pretty sure there is no widely used, actively maintained library using something comparable to spring's template pattern.
So I'd go for the third option. The quotes around "own" are there because I'd make use of the spring RestTemplate code (as of spring version 3.0). As spring is using an Apache 2.0 license you may use and repackage part of the code.
Start from a stripped down version of RestOperations (versions later than spring 3.0 add methods to this interface, e.g. using ResponseEntity, so really start from 3.0). Continuing with the code from RestTemplate you may get frustrated at first, as spring is dragging in quite a few classes introduced in spring 3.0 (MessageConverter stuff, ...). But this is due to the modularity of spring, not due to large amounts of code.
Just make sure you have a canonical way of mapping the spring packages to your own name space, so not to get confused.
Incorporating spring's source code using patterns you use in other projects (like the template mechanism) is imho a great way of getting a deeper understanding of the code base you usually just consume; another benefit.
I'm updating my spring project from 3.0.5 to 4.0.3.
Everything's building fine, but at boot time, when spring tries to create beans, I'm hitting this error message:
The class is of course not present in ehcache-core, hibernate-ehcache, or hibernate-core. In fact, the package spi just isn't present anywhere it seems. However, I've checked the maven dependencies, and it seems like spring 4.0.3 and hibernate 3.6.10 should be fully compatible. In my pom I directly depend on hibernate-ehcache, which in turn pulls in the appropriate version of ehcache-core automatically(apparently the done thing), like this:
My dependencies look like:
I've searched extensively for this error, but can only find a couple of references to it. Given it's obscurity, I'm guessing it's a configuration within my project somewhere that's referencing this RegionFactory class, however, despite much searching, I can't find a thing.
Any ideas how I can get this project building with spring 4.0.3??
I can provide any additional data you need.
The key is to get the project building against Spring 4.0.3.Release. Whatever version of hibernate or ehcache enables me to do that doesn't really matter. Obviously My preferencs would be pom changes over reconfiguring over changing code... but I'll take what I can get at this point.
EDIT:
I'm trying to avoid updating my hibernate past 4.x.y as this project is very large and uses HibernateDaoSupport and HibernateTemplate very extensively (thousands of independent usages which would take a long time to refactor)
Update the Hibernate Version.
After Hibernate version 4.0.0.Final they chage the package from RegionFactory.
3.6.10.Final:
org.hibernate.cache.RegionFactory
4.0.0.Final:
org.hibernate.cache.spi.RegionFactory.