I am trying to upgrade my libraries: ApacheCXF 2.7.7 --> 3.1.4. Spring 2.5.5 --> 4.2.4.
My Hudson build keeps failing because it cannot find packages/classes, org.springframework.context.ApplicationContext, for example. The classpath in cxf-manifest.jar, as part of ApacheCXF, refers specifically to Spring 4.1.7 jars.
I've tried loading both Spring 4.1.7 and 4.2.4 versions, but no joy. (Is loading multiple lib versions even possible?).
I've tried removing cxf-manifest.jar from the classpath/buildpath. Eclipse is happy with that and it finds the desired classes in the Spring 4.2.4 jars, but Hudson is still not happy.
I've considered moving to Spring 4.1.7, but I don't see the point of upgrading partially.
Is ApacheCXF 3.1.4 specifically incompatible with Spring 4.2.4? And how would I get Hudson to be happy with the upgraded libraries?
Turns out that I forgot to add the specific directory containing the Spring jars to my build.xml script.
ApacheCXF 3.1.4 IS compatible with Spring 4.2.4
Edit: Apparently I was wrong.
Related
In the help.md file it's telling me that JVM was changed from 11 to 17
this is what the help.md file looks like
The following was discovered as part of building this project:
* The JVM level was changed from '11' to '17', review the [JDK Version Range](https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions#jdk-version-range) on the wiki for more details.
and here is an example of later problems
And even if i change the project structure manually to java 11 sdk
i have issues with versions next .
This problem is occurring in the newer version of Spring Boot. So when creating project using Spring Initializr or Spring Starter Project select the older version of Spring Boot (like 3.0.1 or 2.7.7).
This should solve the problem.
I upgraded the project to Java 17, Spring Boot 2.7.4 version. And I migrated from Couchbase SDK 2 to SDK 3. After that, I faced an issue with package com.couchbase.client.java.query.dsl. It was not supported, so I added to the project package com.couchbase.client.java.query.dsl manually. After that, issues are fixed. Now, I have a problem, my test case coverage is down. Do you have any idea to fixed it or do you know convert package com.couchbase.client.java.query.dsl to lib file or jar file?
What would be the best possible options?
I'm on a project where we're trying to upgrade dependencies to address security vulnerabilities, but I'm completely new to Spring Boot.
Previously, the spring dependencies were on versions 2.0.4.RELEASE, but the app doesn't work after upgrading to 2.2.13.RELEASE. The app can still compile using Maven after changing the dependencies.
Is there anything in particular that I should be taking note of when upgrading between these two versions? Have checked that all dependencies in the project that were previously on 2.0.4 were upgraded to 2.2.13.
The errors should be printed to std out / console log when you run your application. As guessing, circular dependency can cause service to not start. With the errors you get, things can be clearer.
I'm upgrading a Spring project's Spring version5.1.5.RELEASE which requires an upgrade to Hibernate 5.
I checked the jasypt maven repo but it doesn't seem to have a Hibernate 5 supported version yet.
What's the way to get around this? I don't even know if a Spring 5.x compatible jasypt is on its way.
Edit: I have already checkout out this github repo and have opened an issue on it. I couldn't get it to compile.
jasypt hibernate support is officially available now, here's a link to its maven repo.
My plugin for FishEye should have a possibility to accessing the our Active Directory and implement some more features for FishEye. The plugin should make the synchronization with directory every X minutes, so it is based on SAL Scheduler.
When I tried to use com.sun.jndi.ldap.LdapCtxFactory, I found that is works only with REST plugin, but using with SAL does not load this classes even when I re-defined the classloader.
Anyway, I re-implemented my functionality with the Spring LDAP and when I tried to deploy my plugin to the FishEye I got:
2014-12-03 23:12:03,010 ERROR [ThreadPoolAsyncTaskExecutor::Thread 9 ] org.springframework.osgi.extender.internal.activator.ContextLoaderListener DefaultOsgiBundleApplicationContextListener-onOsgiApplicationEvent - Application context refresh failed (NonValidatingOsgiBundleXmlApplicationContext(bundle=com.mycompany.fisheye.ldap-restriction-plugin, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/osgi]
Offending resource: URL [bundle://84.0:0/META-INF/spring/atlassian-plugins-component-imports.xml]
Ok. I googled and found https://developer.atlassian.com/docs/faq/troubleshooting/dependency-issues-during-plugin-initialisation
There is written that I have to change the scope of dependency to provided for avoiding the conflicts. Ok, I made that. But now I have another exception:
Exception in thread "PluginSchedulerTask-com.mycompany.fisheye.LdapRestrictio nComponentImpl:job" java.lang.NoClassDefFoundError: org/springframework/ldap/core/support/LdapContextSource
I tried to put the spring-ldap-core-1.3.2.RELEASE.jar to $fisheyeDir/lib and nothing happens - the bootloader does not pick up this JAR.
Does anybody know what can be done in this situation? Should I use another LDAP framework or it is possible to shove these ldap client implementation to the classpath?
FishEye version 3.6.1 (latest), spring jars into classpath version 3.0.5.RELEASE. My spring-security-ldap dependency is also 3.0.5.RELEASE.
Thanks in advance.
The Spring version FishEye uses internally (3.0.5 in 3.6.1, 3.1.4 as of 3.7), is not exposed to plugins.
Instead they get a spring runtime from the Atlassian plugin system (https://bitbucket.org/atlassian/atlassian-plugins). FishEye uses plugins 3.0.x, so the Spring version that's available to plugins is 2.5.6.
Neither FishEye, the plugin system nor any of the bundled plugins include spring-ldap, so you can't set the dependency scope to (as this causes the library not to be included in the plugin jar, instead expecting it be available via an OSGI import).
So what I believe you should try is to bundle a version of spring-ldap that's compatible with Spring 2.5.6. To solve the BeanDefinitionParsingException, you might need to exclude some transitive dependencies that are provided by the plugin system (use mvn dependency:tree to find those).
Disclosure: I'm a dev working on FishEye/Crucible