I'm trying to write some Java which allows me to clear cache, but is there a problem where I use CacheManager.getInstance()... the error is:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
When I add commons-logging-1.1.3.jar to the project the error is:
net.sf.ehcache.config.ConfigurationFactory parseConfiguration
WARNING: No configuration found. Configuring ehcache from
ehcache-failsafe.xml found in the classpath:
jar:file:/C:/Users/olawzi/Downloads/ehcache-1.2.3.jar!/ehcache-failsafe.xml
You solved the first issue correctly, by adding its dependency commons-logging.
The second one is, as stated, a warning and not an error (but nevertheless, I'd consider it a very serious warning, as the used defaults are quite probably not good for your application). It means that you forgot to add ehcache.xml, ehcache's configuration file, to the classpath. Add that file and the message will go away.
Also note that the ehcache version you seem to be using (1.2.3) is very old, it was released in 2006. The current version is 2.7, and it can be downloaded here. Instructions for Maven based projects are also on that page.
you should use maven or gradle to manages jar dependencies: it will bring the good version of all jars: otherwise your problem will be hard to fix
Related
I have a scratch file using guava collections, and I get some weird errors that I have to assume is due to the editor and the actual run environment assuming different versions of the guava collections:
Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.common.collect.Range.<init>(Lcom/google/common/collect/Cut;Lcom/google/common/collect/Cut;)V from class
com.google.common.collect.Ranges
at com.google.common.collect.Ranges.create(Ranges.java:80)
at com.google.common.collect.Ranges.closedOpen(Ranges.java:114)
at Scratch.main(scratch_2.java:69)
Not that I can actually know that for sure because I also can't figure out how I'm supposed to see which version the scratch file is pulling in. I've removed guava from my project's deps ENTIRELY and the scratch file still works... WHY? Where is the library coming from??? The scratch run config is completely empty of anything that would dictate this:
And yet it still runs just fine. I discovered that if I delete the guava entries from my local ivy cache, it won't run anymore. If I then add guava back to my project's deps, it ends up in my ivy cache again, and then even if I remove guava from the project deps the scratch file is fine again. So does the scratch file just pick a random version or something? The ivy cache, which is at ~/.ivy2/cache/com.google.guava, looks like this:
But there's also that "jars" folder that has a guava-12.0 for some reason:
And again, I have no idea which version is being used, or why the cache has so many different versions of it. Any ideas?
One way that proved to be the simplest to me was to select "use classpath of an existing project module" (which has dependencies configured) in the run configuration dialog. This is useful if you want to pull out a piece of functionality from your project to play with in isolation but still use the configured dependencies.
I had a similar issue in PyCharm that I just fixed - so your mileage may vary here. It terms out that there was a Python virtual environment attached as the default to the project window (I had had multiple projects open in the same window - but evidently the first one became the default).
I dug into the list of interpreters, found the one I wanted and edited its properties, specifically Associate this virtual environment with current project.
I checked that box for the virtualenv that had the libraries I was looking for and this fixed the compilation errors in the editor itself.
I have a huge web application that I have to support. Recently when I downloaded the latest source from SVN and try to run it locally on Tomcat 6, I get the following error from one of the background batch jobs that the application runs...
2014-12-23 18:08:27 [taskScheduler-4] TaskUtils$LoggingErrorHandler [ERROR] Unexpected error occurred in scheduled task.
java.lang.NoSuchMethodError: javax.xml.stream.XMLEventFactory.newFactory()Ljavax/xml/stream/XMLEventFactory;
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor$HeadersProcessor.<clinit>(ReadHeadersInterceptor.java:275)
So I believe the problem is the Apache class ReadHeadersInterceptor which my application's code calls is trying to call the newFactory() method from XMLEventFactory but is not finding that method, probably because it is reading an older version of XMLEventFactory.
I think this is happening because there are some JARs in my lib folder I need to remove or add. Problem is I don't know which one. I see there are several JARs which have XMLEventFactory including..
woodstox-core-asl-4.2.0
stax2-api-3.1.1
And it is also part of Java 6 in the rt.jar.
So out of all these Jars which one is it trying to read and not find that method it needs?
Thanks.
This is a problem with specific version of JDK/JRE 1.6 (I mean the update). It may looks weird but the JDK API change for specific major version.
Please take a loot at the following link. You can see there that with change from version 1.6.0.17 to 1.6.0.18 the new methods have been added on the XMLEventFactory class.
Probably you have the JRE version less thank 1.6.0.18. I've had the same problem with Apache CXF and dynamic proxies. The update of JRE 1.6.0.14 to 1.6.0.19 fixed the issue.
I hope it helps.
I have a requirement to create a word document. So I am trying to use docx4j. I get a runtime error.
java.lang.NoClassDefFoundError: org.docx4j.openpackaging.packages.WordprocessingMLPackage
I am sure I have docx4j3.0.1 and all the dependencies added to my build path.
Is there an issue with the class initialization mechanism?
Any ideas?
Had to add all the jars to the MQSI/shared-classes folder. That worked.
For future reference a good way to resolve these problems on IBM JRE platforms is to set the environment variable IBM_JAVA_OPTIONS=-Dibm.cl.verbose=* and restart the Broker.
This will cause classloading trace to be written to Broker's standard output (located in $MQSI_WORKPATH/components//
This shows you what jars are available in each classloader and which classloaders are being searched whenever a class is loaded.
When working with JBuilder2008 my project would build successfully. I changed to MyEclipse and found the following issue:
request.setCharacterEncoding("UTF-8"); has got a red line below setCharacterEncoding and it has below problem message:
The method setCharacterEncoding(String) is undefined for the type HttpServletRequest
Could you tell me what shall I do?
I think that the problem is that your Eclipse is configured to use an older version of the servlet APIs; see this forum post. (Right at the end.) The method is certainly present in the Java Servlet 2.4 APIs.
(FWIW, I pick up my Java Servlet APIs via an explicit Maven dependency, so I'm not hostage to the default version implied by my IDE settings.)
Inside MyEclipse IDE, please add 'javaee.jar' in your Project's build-path. This will solve your mentioned error about "request.setCharacterEncoding("UTF-8") "
Usually, during run-time (within web-server container) this jar will be already in classpath. But during development inside IDE, you may face this compile time error.
You will find this JAR at path depending upon your installation path:For example,
C:\MyEclipse6.0\myeclipse\eclipse\plugins\com.genuitec.eclipse.j2eedt.core_6.0.0.zmyeclipse60020070820\data\libraryset\EE_5
I get this message :
javax.xml.parsers.FactoryConfigurationError:
Provider
org.apache.xerces.jaxp.DocumentBuilderFactoryImp
but i can't seem to solve the problem. I have googled, but can't find any good solutions.
Does anyone have an idea of what could be wrong?
And maybe how to solve it :)
The org.apache.xerces is from the Apache Xerces package, and something in your application has a dependency on it. Try downloading it (latest version is 2.9.0) and adding it to your application's classpath.
DocumentBuilderFactory has a multi-step process for finding the actual parser implementation, as described in the linked JavaDoc. Your error message is almost certainly coming from there.
I suspect that your JBoss startup script is setting the javax.xml.parsers.DocumentBuilderFactory system property incorrectly (I've seen this happen before, used to avoid a bug in the released library). I would start by grepping the JBoss configuration directory for that property, followed by explicitly setting the jaxp.debug property (also described in the link). Assuming that your startup script is indeed explicitly setting the property, find out who made that change and ask him/her if you can delete it (or to provide you with the correct JARs if not).
As you've tagged your question JBoss, I'll assume your code is running in the JBoss container.
JBoss may have already loaded a version of Xerces for it's own use and you're trying to load a different version in your code (either explicitly or through some dependency) and the configuration for your version is not compatible with the version that's already loaded.
This JIRA Ticket on JBoss.org suggests deleting the xercesimpl.jar in jasperserver/WEB-INF/lib folder to allow your version to be used.