My code is built in maven and using jBoss 6 and java 7
The code is working fine on local machine but when i try running war on server i an getting error
ERROR [org.springframework.web.servlet.DispatcherServlet]
I tried using aop jar but still no success
Can some one explain me the error and how to solve it
It is failing during the creation of your #Beans. In particular, it is failing because NoClassDefFoundError: org/springframework/core/convert/converter/ConvertingComparator which means it can't find the Class definition for "ConvertingComparator". The earliest documentation I can find on the ConvertingComparator is Spring
3.2.0. Bear in mind, you are using Spring 3.1.0.RELEASE. I tried running a basic Spring project using your POM and ran into similar issues using the spring version you provided. I also ran into conflicts with Spring 3.2.0. I recommend using Spring 4.3.5.RELEASE in your POM. I had no issues running my basic example after setting the properties you have to:
<properties>
<org.springframework.version>4.3.5.RELEASE</org.springframework.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
That being said, you may have other issues in your code as well. It is difficult to provide a holistic solution without more information.
EDIT:
So here are all your spring dependencies:
spring-beans
spring-web
spring-webmvc
spring-tx
spring-jdbc
So first lets talk about redundancy. spring-webmvc actually contains spring-web and spring-beans. You can therefore remove those dependencies from your POM as they are redundant. spring-jdbc contains spring-tx, rendering that inclusion also redundant. You can remove all of those from your POM right now for clean up.
In your comment, you mentioned a new error being thrown in regards to package org.springframework.mail not being found. This package is found in spring-context-support. Spring context support is actually found in the spring-webmvc as well as an optional dependency. (so you would have to include it manually)
According to this thread, that package was moved into context-support separately. My guess is that you are trying to specifically use some of the objects available in the .mail package and because you were not including it, it wasn't being found. With more information as to your project, the more we can dive into why 3.2 did not work and 4.1 does work. Specifics aside, what this all means is that the 3.2 dependencies you were calling did not expose the required packages, but the 4.1 dependencies do.
Have you stopped the process, I mean that particular bean could be in-use ?
Related
I have a legacy monolith application, which uses elasticsearch 1.X and now we need to run elasticsearch 7.X in the same application, so that same application index and query data in both version of elasticsearch.
In my project, there are multiple modules and they all have their own POM and parent POM, and my new module which uses elasticsearch 7.X depends on some module which uses 1.X.
Although I have excluded 1.X specific dependency in module which uses 7.X, Still it gives me below Error:
[76B7CCD2] java.lang.NoSuchFieldError: LATEST at
org.elasticsearch.Version.(Version.java:49) at
org.elasticsearch.common.io.stream.StreamInput.(StreamInput.java:114)
After doing a lot of research and using this and this link, As explained I excluded the elastic 1.x dependency but still looks like as my other sub-module still has ES 1.X and which is required as well, hence overall classpath of my application has both versions of org.elasticsearch.Version java class from the same package org.elasticsearch, which I feel is the root cause.
Now, How can I include the same class from the same package from two different versions of a same library.
You can't. You can only have one class with a given full qualified name (package + name).
You can try to shade one of the packages (i.e. rename it) with the Maven shade plugin (never tried that, actually), which might work.
Usually, you need to change code and fiddle around until you find a version of elasticsearch that works with all dependencies.
I have a spring web rest project (3.0.4) running with aspectJ (1.8.14) for logging.
I have a pointcut defined in all methods that are annotated with #Logging.
When I call a generic helloWorld controller annotated with #Logging. AspectJ works fine.
When I call the real controller annotated with #Logging, which also happens to call a lib jar method that is also annotated with #Logging. Unfortunally, during the inner method call the error below occurs.
How does it come that only the method inside the lib has such error?
java.lang.NoSuchMethodError:
logging.aop.LoggingAspect.ajc$inlineAccessFieldGet$logging_aop_LoggingAspect$logging_aop_LoggingAspect$pLogger()Lorg/slf4j/Logger;
service.impl.DAOClass.getMethod_aroundBody1$advice(DAOClass.java:101)
service.impl.DAOClass.getMethod(DAOClass.java:1)
What I tried: I checked jdk compiled versions, jar versions in maven dependencies, web.xml and aop.xml configuration and installing AJDT plugin for eclipse photon to debug. I tried to deploy in weblogic to see the class loader, but I was not able to, trying in tomcat i cannot see what is loaded or not.
P.S: please do not downgrade the question for lack of code, i would have to make a complete mock to avoid showing company code for now I am looking for people that worked with AOP with spring and has some idea what I am using based on this info plus the error stack. I can make a mock code later if nobody guess what is the cause until there.
Thanks!
No SuchMethodError usually happens when runtime class path contains different version/both version of jar the library was compile against. You should check the pom dependency against runtime class path. I bet it was promoted to newer version which is not backward compatible. How do you package your application, spring boot?
I have to use a library so I looked it up in our repository and added it to the dependencies. When starting the Weblogic server I got a DeploymentException (Ambiguous Bean Name).
I found out that this means that I try to register Beans with the same name twice or more.
Then I found out that this library is already provided by the server (JEE Container). Therefore this exception makes sense. I then changed the scope of the dependency to provided and the version to the one provided by the container.
But then I got a build error because the dependency can't be resolved with that version. I checked our repo manually and saw that this is true.
version provided by container: 1.0.4
version existing in repo: 1.0.7
How can I resolve this issue? I just want to tell maven that it should use the library which will exist when deployed. And ignore the fact that it's not available during compilation. (If this is even possible)
I think you misunderstood some aspects of "provided".
Giving a dependency as "provided" means that it is only used for compilation but not packaged into your war/ear. This implies that it does not make sense to specify a dependency as "provided" if it does not exist in the repository.
The usual way to solve your problem would be to specify the dependency with version 1.0.7 and make sure that you do not call any class/method that is not present in version 1.0.4.
Your application will then compile against 1.0.7 but runs with 1.0.4 which is fine in most cases (note that Java cannot check or know the versions of the included jars - the only risk is that 1.0.7 has different interfaces than 1.0.4 which is unlikely if only the last part of the number changed).
I am using Spring 4.3 and Servlet 3.1.
Deployment fails with error
javax.servlet.ServletContainerInitializer: Provider org.springframework.web.SpringServletContainerInitializer not a subtype.
I know that it is some wrong class is loading
The Spring jars and Servlet 3.1 jars are configured as a module and mentioned in module.xml.
javax.servlet.ServletContainerInitializer is present in only one jar jboss-servlet-api_3.1_spec-1.0.0.Final.jar that I have included in module.xml.
SpringServletContainerInitializer is needed for my application.
Let me know if you need me to post more details.
Any help is appreciated.
I had the same problem and solved it by goig through my dependencies to see if anything crashed with my application-servers libraries.
Make sure your java-ee and java-ee-web dependencies are set to "provided" scope in your maven/gradle configuration.
I was getting the same error and after researching, I identified somehow SpringServletContainerInitializer was not loading because of Maven packaging issue. In my case, spring-web-4.3.8.Release.jar was not bundling correctly with application WAR.
This can be fixed by
resolving application bundling conflict
using server shared libraries
if using IDE for application bundling, one can avoid bundling using IDE or switch the IDE (like STS to Eclipse/RAD)
Another potential source of extra copies of servlet-api and other similar Java EE APIs is Spring Boot's tomcat-embed-core-<version>.jar, which you may get from spring-boot-starter-web.
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