I'm developing a Java Web Application with Spring 5 (not Spring Boot) and I'm facing a problem with the library spring-ladp-core (2.3.2.RELEASE).
I get this error:
java.lang.NoSuchMethodError: org.springframework.util.ReflectionUtils.accessibleConstructor(Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/reflect/Constructor;
at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:155)
and I can't understand exactly what's the problem, maybe a dependencies version problem but I don't know how to solve it. I mean the spring-ldap-core is no more updated since 2017 so is it outdated? Is supposed no longer be used?
I need to build an authentication mechanism with Spring security and LDAP, is the spring-security-ldap library the correct way to implement this?
I have an "old" project with Spring 4 and spring-ldap-core and it works fine, is spring-ldap-core no more compatibile with recent versions of Spring (Spring > 4)?
Thanks.
Related
I have been trying to set up a Spring Web application to use Azure Active Directory.
All the samples that I have found online are based on Spring Boot, is there a simple example that shows setting up spring framework web app only without using Spring Boot?
I am having no luck finding stuff, I am also trying to figure out how to convert all the spring boot autoconfig. Surely there is a sample somewhere that makes it easy to use for a Spring Framework only web-app?
I was able to figure this out somewhat. I'm very new to OAuth so still trying to learn as I go.
Basically I followed the Spring Reference and got things working using the override auto-configuration sections at https://docs.spring.io/spring-security/reference/servlet/oauth2/index.html
It also helped that I updated the Spring Framework versions to the latest and made sure I used the correct dependencies according to that reference site
I'm migrating a Spring Boot project from boot 1.5.x to 2.0.x.
In the 1.5.x project I see that the following dependency is being used:
dependencies {
...
compile("org.springframework.security:spring-security-jwt")
...
}
The version of the spring-security-jwt is managed by Spring and I can verify that here. Namely:
<spring-security-jwt.version>1.0.9.RELEASE</spring-security-jwt.version>
The same dependency fails to resolve when I move to Boot 2 because it is no longer managed by Spring. I can verify that here...
Is this a bug or it is removed and included in another lib? Somehow I can't find clues in the docs... Shall I manage the version manually now?
The spring-security-jwt (and OAuth as well I guess) are now obsolete. Spring Security 5 added that support to the core library instead of an extension of the framework.
See here for a list of tickets related to the core JWT and OAuth support.
So in short you don't need that dependency anymore, although if you have custom filters and functionality build around that it would require using different classes/packages and features.
our application currently uses JBoss Portal with JAAS as the authentication/authorization mechanism. The version of Spring we are currently using is 3.2.14. For various reasons we are unable to upgrade Spring right now.
We are going to be migrating to Spring Security shortly and are wondering if Spring Security 4.2.2 will be compatible with Spring 3.2.14. My thoughts are that since Spring Security is a separate project it should be OK?
I can't seem to find any information on the compatibility issues between major versions of Spring and major versions of Spring Security.
For Spring Security 4.2.2, the minimum recommended Spring version is 4.3.5.
This is stated in the SpringSecurityCoreVersion class which is located in the org.springframework.security.core package.
I am developing a Jersey RESTful service using the Spring framework integration with Hibernate. I get a NoSuchMethodException on a org.jboss.logging.logger.debugf call. As I noticed, the class is indeed loaded from the bean-validator.jar included alongside the jersey-spring3 library, eventhough I have specifically referenced the jboss logging artifact.
Has anyone encountered this issue? And if so, how should I solve it?
Update
I have found a workaround, but it is far from being a solution. In order for the required classes to have the same signature, I have downgraded the hibernate-entitymanager to version 4.2.8.Final. However, this leads the way to other compatibility issues.
Update 2
In the end, I have chosen to implement the REST service functionality using the Spring Framework instead of using the aforementioned integration.
Check out the answers in the following post, your issue might be similar:
Error "java.lang.NoSuchMethodError: org.jboss.logging.Logger.getMessageLogger"
According to you what are the risks of using Spring 4 with the jersey-spring3 integration module?
I have tried to use Spring 4.0 with the jersey spring example and the example still works but i'm unable to identify risks linked to this usage.
I have started using Jersey 2.7 and Spring 4.0.x recently in a project. I have setup a context hierarchy to inject beans, so far, I have discovered only one limitiation but that does not seem relate to Spring 4 but rather to the module itself or the HK2 Spring Bridge.
To give more insight about my use. I have a XJC/JAXB-backed which is consumed by a common service, repository and exposed through JAX-WS, and now hopefully through JAX-RS.
The multi-context stuff works now with #Autowiredwith 2.8-SNAPSHOT. I have applied my changes and the 2.8-SNAPSHOT to 2.7. Here is the diff.
Edit (Michael-O; 2014-10-17): Here is a modified Spring module based off 2.11 with multi-context support.
Not an answer to original question, just related information
This may be a little premature, but the new Major 3.0 version of Jersey will be using Spring 4, in the new jersey-spring4 module. The new Major version will be built with Java 8. Though a new Major version will be released, the 2.x line will still be actively developed to keep support for Java 7
I'll update this post once 3.0 has been release.
For anyone interested, you can see this mailing list to see what the Jersey team has to say about the new 3.x line.
Not sure if you came across any issues but I currently face one. It is described in other thread.
Simply, using jersey-spring3 2.12 and spring 4.1.0.RELEASE in one maven project leads to following class incompatibility:
2014-09-14 01:15:44.175:WARN:oejuc.AbstractLifeCycle:main: FAILED org.eclipse.jetty.server.handler.HandlerCollection#696
db620[org.eclipse.jetty.server.handler.ContextHandlerCollection#27abb6ca[o.e.j.m.p.JettyWebAppContext#737d100a{/,file:/C
:/Users/Josef/Workspace/TransitCenter/src/main/webapp/,STARTING}{file:/C:/Users/Josef/Workspace/TransitCenter/src/main/w
ebapp/}], org.eclipse.jetty.server.handler.DefaultHandler#6968c1d6, org.eclipse.jetty.server.handler.RequestLogHandler#7
d986d83]: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependenc
yComparator()Ljava/util/Comparator;
java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparato
r()Ljava/util/Comparator;
at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationCon
figUtils.java:136)