I have a large project with lots of dependencies packaged as a 'jar-with-dependencies.jar'. I place this jar in jmeter's /lib folder.
When I try to start Jmeter and open a jmx file I get Uncaught exception error like,
Uncaught Exception java.lang.NoSuchMethodError: com.thoughtworks.xstream.core.JV
M.newReflectionProvider()Lcom/thoughtworks/xstream/converters/reflection/Reflect
ionProvider;.See log file for details.
I plan to write a BeanShell Java code that would use the functionalities within the custom jar imported. Am I importing the jar in the right way? Is there any other way to import the jar?
This class is contained in the xstream.jar, and JMeter already has its own version of xstream.jar (JMeter 2.13 and 3.0 include xstream-1.4.8.jar).
Now, if your Jar with dependencies has another version of xstream.jar, you will have 2 versions of this file in lib folder. And that's not good:
the behavior is undetermined and only at runtime one of the two classes will be chosen. Which one gets chosen depends on the internal implementation of the class loader, there is no way to know upfront.
So you need to remove one of the files. Which one is tricky
Usually keeping the newer version is a safer option. So I'd start from that. If it works - great.
If it doesn't work, try the other way around (although I suspect the error you are seeing coming from some older version of this package)
If second method doesn't work, you will have to open up the code of your custom jar, and update it to be compatible with JMeter (update version of xstream.jar to be the same as JMeter uses, and update any broken code). Or you can try this solution.
Related
I have added spring-web.4.0.jar in classpath. It contains the class - org.springframework.web.context.WebApplicationContext. but when I try to run it in eclipse it shows me an error : org/springframework/web/context/WebApplicationContext.
How to resolve this error?
Choosing "Clean..." from the server contextual menu helped me get rid of this problem.
Try clean and rebuild your eclipse project, because sometimes eclipse gets out of date.
Alternatively, if this doesn't help, you need to verify that the runtime path indeed points to the correct jar, and that the jar does indeed contain the WebApplicationContext.class and is readable.
To see the runtime path, use the debug view (Window - Views- Debug), right click to view properties.
Find the jar and open it with a normal zip viewer to see if the file reads correctly.
The root cause of this problem can be almost literally anything, but here are a few weird things to check:
Maven dependencies with test or provided scope that should be normal scope
Spring XML files have schema versions that don't match framework version (3.0 or 4.0)
Spring XML references "https://" instead of "http://" or vice-versa (depends on version)
web.xml file containing ${} references not compatible with chosen web server
Conflicting version of very core libraries such as Jackson, Servlet API, spring-*
Misconfigured or missing or incompatible loggers: slf4j, log4j, jcl
Mixing of old and new: jdk version, spring version, dependency versions, IDE, server
Maven dependencies not showing up in Deployment Assembly (this one went away with upgrades)
Stale or locked jarfiles... may require a reboot, tomcat "Clean..." not enough
Missing required -D or environment variables
My application ended up with several of these all wrong one after another.
The exception is misleading. Setting a debugger breakpoint on the exception sometimes helps.
I'm using Fiji for the first time, I need to open an image as a FloatType so I followed the example found here http://fiji.sc/wiki/index.php/ImgLib2_Examples#Example_1b_-_Opening_an_ImgLib2_image but I get this error:
WARN: Ignoring non-Maven build directory: /home/utente/workspace/my_project/bin
Exception in thread "main" java.lang.IllegalArgumentException: No compatible service: io.scif.SCIFIOService
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:222)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:176)
at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:153)
at org.scijava.Context.<init>(Context.java:200)
at org.scijava.Context.<init>(Context.java:127)
at org.scijava.Context.<init>(Context.java:116)
at io.scif.img.AbstractImgIOComponent.<init>(AbstractImgIOComponent.java:65)
at io.scif.img.ImgOpener.<init>(ImgOpener.java:99)
at SGP_db.StartingJFrame.getGn(StartingJFrame.java:216)
at Plugin.SGP_deblurring_boundary.main(SGP_deblurring_boundary.java:58)
Can't undertand why I get this error, any ideas?
Thanks,
sara
It is almost certainly a build path issue in Eclipse. Are you using the M2E plugin to manage your projects?
If you are not, or aren't sure, please follow the directions on the Fiji web site at:
http://fiji.sc/Developing_ImgLib2#Developing_ImgLib2_with_Eclipse
I would strongly suggest not to manually juggle JAR files in non-Maven Eclipse projects. The Eclipse Maven integration will make your life much easier. For more details, see:
http://fiji.sc/Maven
I've solved importing the ImgOpener class from imglib2.io
Please note that imglib2-io no longer exists; the up-to-date way to access the ImgOpener is to use the io.scif:scifio library instead. If you are basing your work off of the ImgLib2 Examples, please note that you can grab the source from GitHub, which includes a Maven POM with the correct dependencies specified. Start from there, or from the minimal-ij1-plugin project if you need to use ImageJ 1.x routines as well.
I'm using STS, and with a Web (WTP); Maven; Groovy stack.
By default, it appears that the Groovy classpath entries weren't marked to be exported, and I was issued with the following warning:
Classpath entry GROOVY_DSL_SUPPORT will not be exported or published.
Runtime ClassNotFoundExceptions may result. Classpath entry
GROOVY_SUPPORT will not be exported or published. Runtime
ClassNotFoundExceptions may result.
So, I added the libraries from Project Properties -> Deployment Assembly -> Add...
However, now I get the following error:
Invalid classpath publish/export dependency
/Users/martypitt/springsource/2.8.1.RELEASE/sts-2.8.1.RELEASE/plugins/org.codehaus.groovy_1.8.4.xx-20111212-0900-e37-RELEASE/lib/antlr-2.7.7.jar.
The project contains another dependency with the same archive name.
I worked around by excluding antlr manually from my pom.xml. However, this seems counter-intuitive, and leaves me concerned about issues later when I deploy to a server outside of STS.
Is there a more appropriate way to resolve this issue?
You do not need to export the DSL support container. It provides editing support for some built in Groovy AST transforms. There is nothing in the classpath container required for compilation or runtime.
Looks like your project is groovy project. Go to eclipse and install groovy addon - from software site - http://dist.springsource.org/snapshot/GRECLIPSE/e4.6/
After this restart eclipse and you should have these in path/eclipse to work with.
Detailed instructions # https://github.com/groovy/groovy-eclipse/wiki
Make sure you have the proxy configured properly - if any.
I have been assigned a job to compile an old Websphere(WAS4) project, so we can find out which parts of it need to be changed for the project upgrating( to WAS7).
But when I was trying to fix the jar errors, wesphere.jar is missing!! And WAS7 installation path never hava this jar anymore, searching google failed. And I don't like to install older WAS again to just get this jar.
please anybody can help with this, providing an WAS4 version webspere.jar???
TKX in advance!
The jar file itself isn't important, the classes within it are. I don't recall what was in websphere.jar, but there's a good chance that what was is now in j2ee.jar. In fact, if your code isn't using any WebSphere-specific extensions, there's a good chance j2ee.jar is the only jar from WebSphere that you'll need for compiling.
But you should be able to see what specific classes are being complained about by the compiler and if necessary search for those by opening the jar files in like WinZip.
(Keep in mind that the larger changes are the changes to J2EE and Servlet specification levels.)
JDeveloper 10.1.3.x
I've recently learned that a library that is not exported will not be included on the classpath when deployed to the embedded OC4J container because it will have no library entry in the application-oc4j-app.xml file.
I have also demonstrated to myself that libraries that are not exported in projects that my project depends on are included in the application-oc4j-app.xml file.
Unexported libraries in my project do not get included. Unexported libraries in my project dependencies do get included.
Is that a bug or a feature, and can I change that behavior such that unexported libraries in my project dependencies also do not get included?
Thanks,
Steve
Unexported libraries should not get included in the application-oc4j-app.xml file. It looks like there is a bug, or some inexplicable behavior in JDeveloper.
IMHO, given a choice between Eclipse or <insert another IDE here>, and JDeveloper, it is wise to choose Eclipse.
One of the inexplicable behaviors that I referred to earlier, was the issue with JDeveloper compiling all projects in the application's directory, even if they were not part of the current workspace file (jws file). In other words, JDeveloper will consider a JPR file for inclusion in the workspace, even if the JWS file states otherwise (i.e. is does not appear visually in the JDeveloper workspace).
To date I have not found a way to specify different classpaths for build vs run time, but with help from a colleague, a solution to my specific situation was stumbled upon. Even though the connector is not a JDev project, the dependent project can reference the log4j jar file that is packaged and loaded with it. That effectively mimics the behavior at runtime, for both standalone as well as embedded oc4j container deployment, in which the web application and associated application code link to the log4j instance loaded by the 3rd party JCA connector's classloader. I did not think this would work assuming that a log4j library loaded by two different classloaders would still appear to be two distinct instances of the library with respect to log4j's static initializers. (That is what I am presuming motivates log4j to throw an exception if it finds another instance of itself in the classloader hierarchy.) Apparently this is not the case, at least for the embedded scenario. I do not have to test this for the standalone container since the Maven build knows not to include a copy of the log4j library jar in the application EAR file via the "provided" scope specification in the build file. The embedded OC4J container now loads the JCA connector, the associated log4 library instance, deploys the application, and allows both to use the log4j classes from the same log4j library file. Not entirely sure of how the connector and web applications classloaders interact, but it works now.