The projet work fine in tomcat localhost but when I upload it in a remote tomcat I get this bug :/ , I have the jar that contain the ImageReaderFactory class in classpath, I didn't understand what can be the problem,
I cleared the /tomcat/work/Catalina/localhost folder but always the same bug : java.lang.NoClassDefFoundError
07-Oct-2019 23:06:25.584 SEVERE [http-apr-8080-exec-267] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [UploadServlet] in context with path [/MyServer] threw exception [Servlet execution threw an exception] with root cause
java.lang.NoClassDefFoundError: org/dcm4che3/imageio/codec/ImageReaderFactory
at org.dcm4che3.imageio.plugins.dcm.DicomImageReader.setMetadata(DicomImageReader.java:794)
at org.dcm4che3.imageio.plugins.dcm.DicomImageReader.readMetadata(DicomImageReader.java:713)
at org.dcm4che3.imageio.plugins.dcm.DicomImageReader.read(DicomImageReader.java:452)
at com.project.dicomserver.UploadServlet.getFrameIcon(UploadServlet.java:86)
....
Does anyone have any ideas?
image
There is a bunch of things that could be go wrong in your specific case. So answering with the best of my knowledge. Make amendments, by adding as much details as possible, to the question and we can help you further.
Every application in tomcat needs to have a specific folder structure. The folder structure is documented here. In short, war files must be deployed into $CATALINA_BASE/webapps/ directory.
So if your application is "myapp", then there must be a $CATALINA_BASE/webapps/myapp directory.
Inside $CATALINA_BASE/webapps/myapp directory, we need to have WEB-INF. Not $CATALINA_BASE/webapps/myapp/WebContent/WEB-INF, but $CATALINA_BASE/webapps/myapp/WEB-INF ! And the case matters.
If this is not how your application is deployed into a vanilla tomcat, it will not work properly. Read the official documentation
Now about your development environment, see whether your eclipse configurations have been modified. The Export As War options can be modified at multiple locations and all of them can have impact on the war file you have generated. When in doubt, I look at this link
Use a build tool like maven or gradle. These tools bring standards for compiling, archiving, testing and deploying applications and makes you worry less on environment related issues.
Related
I am deploying one war file on WebLogic server (12.1.3.0.0) but when I try to start that application to serve all requests. It get failed with the following error message:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#0': Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.springframework.web.method.annotation.ExceptionHandlerMethodResolver.hasExceptionMappings()Z .
The same war file is working fine on Windows platform and other Linux machines but I am getting that error on one particular Linux machine so my understanding is that there is something missing (e.g. some package) on this machine but I am unable to identify that what exactly.
It means "I cannot find the method hasExceptionMappings inside class org.springframework.web.method.annotation.ExceptionHandlerMethodResolver"
Please check if the spring jar version that the WebLogic using is different when you are compile the WAR. The spring library could be a shared library, you may check the classpath first.
FYI: https://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#WLPRG319
If this code works on other machines and is definitely an identical deployment, then the difference must be on the machine where you are deploying it. I agree you should check the versions of the Spring files that are provided on this server against those where it does run successfully. When you find a difference you will know what needs fixing.
I have to confess that I am not familiar with jboss, but I have a task to launch application that works on top of it. The application was running before restart but is not able to get launched after. The following exception is raised on attempt to run it:
12:40:08,680 INFO [TomcatDeployment] deploy, ctxPath=/
12:40:08,777 INFO [TomcatDeployment] deploy, ctxPath=/geoserver
12:40:08,971 ERROR [JBossContextConfig] XML error parsing: context.xml
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextConfig.java:557)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:543)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
Are there any typical causes for this problem?
This error is usually thrown when you package XML parser jars (eg. xerces or SAXParser) in your deployment artifact (ie. WAR, EAR) files. JBoss provides its own XML parsing libraries which is available to your application as part of the parent class loader. You may also need to re-compile your application against the JBoss run time libraries. A good rule of thumb is to not duplicate jars that are already provided by the JEE container. You can work around it by implementing classloading isolation, however, I think it's best to start by removing the JEE container provided jars first.
I have a problem that I can't figure out.
Context :
was 7.0.0.19 version (with no preCompileJsp)
Caused by: java.lang.NoClassDefFoundError: org/apache/jsp/_xxx (wrong name: com/ibm/_jsp/_xxx) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:275) at java.lang.ClassLoader.defineClass(ClassLoader.java:212) at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.defClass(JSPExtensionClassLoader.java:181) at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader._loadClass(JSPExtensionClassLoader.java:133)
It's the only JSP that give problem, and only on a specific environment (no problem on the others environments with the same configuration) the xxx.class is well present in my profile/tmp directory with others jsp in the same directory (that all give no problem) and the filesystem is not full.
Tests
I did a copy of xxx.jsp to xxxNew.jsp in the same directory
I can access the xxxNew.jsp without any problem (so there is no coding problem)
So I did a mv from xxx.jsp to xxx1.jsp and had no problem to access the jsp new named
I deleted the xxx.class in the tmp directory
I did the mv back to the first name (xxx.jsp) and still get the error with a newly xxx.class in the tmp directory.
Is there a class cache anywhere in websphere that could explain this ? (no cachespec.xml for dynacache found in the war module).
Why Websphere try to find a class from the org.apache.jsp package and not from com.ibm._jsp ? (how the AS choose the mapping from the URL to the classes ?)
Thxs !
Make sure you are not including in your webapp classpath any JSP engine or other implementation of standard JSP libraries that might be incompatible with WebSphere's runtime. Also, once you delete all potentially incompatible jars, try deleting the generated classes from JSP compilation (which are under {WAS_HOME}/AppServer/profiles/{YOUR_PROFILE}/temp), so recompilation would be triggered and discard any stale .class generated with a previous classpath state.
It would be helpful if you posted the list of JARs in your app's classpath.
Try changing the web application class loading policy on the WAS console: PARENT_FIRST / PARENT_LAST.
this bug is due to websphere incorrect log : the original exception is not displayed.
You should check for instance if there is no missing jsp tag libraries in your page.
See https://www-01.ibm.com/support/docview.wss?uid=swg1PI09596
Regards.
I'm working on a java project with spring on eclipse using Maven, and running on a Tomcat server v6.0. Everything was working fine since yesterday morning.
Here his my problem : I'm building my project, I got a build success. Then I start my Tomcat server and got this error :
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:applicationContext- core.xml]
Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [applicationContext-core.xml]; nested exception is java.io.FileNotFoundException: class path resource [applicationContext-core.xml] cannot be opened because it does not exist
I found out similar problem on some website but none of them give me a solution that worked for me.
It seems that eclipse isn't able to find applicationContext-core.xml when I'm doing this :
<import resource="classpath:applicationContext-core.xml" />
However, I do have the needed jar file nad-core-0.0.1-SNAPSHOT.jar in WEB-INF/lib containing applicationContext-core.xml.
I even tried to add it manually to the classpath but I was still having the same problem.
I keep on looking for a solution, when suddendly it work again once after restarting Eclipse and building while Eclipse was still updating indexes and my project was having this strange status Hg status pending instead of default. Surprised by this result I decide to build again my project after restarting Eclipse and I got the error again and I enable to make it work again. It's quite annoying...
This looks to be a really random problem.
Thanks a lot for your help :)
As you've not specified you web application structure. I assume you've a simple web application at hand with the following structures
webapp
WEB-INF/classes/applicationContext.xml
WEB-INF/lib/nad-core-0.0.1-SNAPSHOT.jar/applicationContext-core.xml
Application context.xml refers to the applicationContext-core.xml file using the import tag. I did encounter a similar situation in my web application, here're the check lists that you should go through and may be one of them can apply to your situation.
Check the generated snapshot jar file for the applicationContext-core.xml file and make sure it is in the root directory of the jar. As silly as it sounds, this was the root cause of the issue I faced in my deployment.
Make sure your Maven Pom.xml file is configured to include this XML file from the resources folder. You can use the resource tags in the build phase of Maven to package them within the jar file itself.
You can try removing the import tag from application context.xml file and instead load both of them from Spring's webapplication context itself.
Add a context loader listener class from spring org.springframework.web.context.ContextLoaderListener
Add context-param contextConfigLocation with value classpath:applicationContext-core.xml,classpath:applicationContext.xml. Spring has the ability to dynamically sort out the dependencies before initiating the bean factory.
Hope this check list helps.
I get pretty much the same config, six years later, I got the same error.
I also restart Eclipse, and it solved the issue.
I have a project with the following configuration:
WebSphere Application Server 6.1.0.19
wsdl4j-1.6.2.jar at the $WAS_ROOT/java/jre/lib/ext directory, (to overwrite wsdl4j-1.6.1 included in WAS 6.1).
cxf-2.4.0.jar (and others dependencies) at the $WAS_ROOT/lib/ext directory.
An EAR 'X' with a Web Module 'Y'.
The Web Module 'Y' has a JAR Module 'Z' (at the WEB-INF/lib directory).
'Z' has a set of classes that implement a SOAP Web Service generated using CXF's wsdl2java.
'Y' has a business class (at the WEB-INF/classes directory) that calls the SOAP Web Service Client at 'Z'.
This configuration works well at my development enviroment (Rational Application Developer with a WebSphere AS 6.1 runtime). But at the QA enviroment, I had the following exception, (please pay attention at bolds in the stack trace):
org.apache.cxf.bus.extension.ExtensionException
at org.apache.cxf.bus.extension.Extension.loadInterface(Extension.java:134)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:160)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.getBeansOfType(ExtensionManagerImpl.java:256)
at org.apache.cxf.bus.CXFBusImpl.getExtension(CXFBusImpl.java:99)
at org.apache.cxf.endpoint.ClientImpl.notifyLifecycleManager(ClientImpl.java:186)
at org.apache.cxf.endpoint.ClientImpl.(ClientImpl.java:117)
at org.apache.cxf.frontend.ClientFactoryBean.createClient(ClientFactoryBean.java:104)
at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:92)
at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:152)
at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:464)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:331)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:318)
at javax.xml.ws.Service.getPort(Service.java:46)
at web.service.client.implementation.at.z.module.method(Unknown Source)
at business.class.at.y.web.module.method(AvisoCobroDAO.java:86)
... 32 more
Caused by: java.lang.ClassNotFoundException: org.apache.cxf.endpoint.ClientLifeCycleManager
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:472)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:373)
at java.lang.ClassLoader.loadClass(ClassLoader.java:561)
at org.apache.cxf.bus.extension.Extension.loadInterface(Extension.java:132)
... 51 more
Seems like the CompoundClassLoader (which works at application level) is trying to load a CXF's class which exists at the server runtime level.
I hope somebody help me with this issue. I'll be very very grateful.
Placing Jars in the WAS_HOME/lib/ext should be your last resort.
Always try the PARENT_LAST classloader mode and have your classes/jars picked up first.
This would avoid a number of problems for you.
The App Server start up would use this directory extensively and if there are clashes it might not even start up.
THe best way to troubleshoot is to turn on classloading and look at the native_stdout/stderr file and see who is loading the class(es) that is in question.
Bkail,
Did you mean to say things differently? This path is high up the class loader chain so it would be checked earlier (with the default PARENT_FIRST) class loading policy.
This would be in the second rung (after the BOOT CLassloader of the JDK) and it's extensions.
HTH
Manglu