I know that a java.lang.NoSuchMethodError means that the version of a class used for compiling is different from the version used at runtime. Usually, when I see this issue, I start the app.server in java -verbose mode, which tells me the jar file from which a class is loaded. If that jar file is not the one I intended to use, I know I'm using an incorrect version of the jar file.
Another approach I use, is to use javap to look at the method signatures of the class in the jar file I am using at runtime, to confirm that the jar does indeed contain the class with a different method signature.
I am seeing this error now in Karaf, an OSGi container and none of the above approaches are helping. java -verbose shows me the jar, javap shows me the method signature and the method signature is the same as that in the error stacktrace. In other words, I can see that the class from the jar being used at runtime does have the same method signature that the jvm says it cannot find.
Here is the exact stack trace, if it helps:
java.lang.NoSuchMethodError: org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/axiom/soap/SOAPModelBuilder;
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659)
Are there any other approaches I can/should use? Thanks for your help.
The Karaf commands exports [ids], imports [ids] and classes [ids] can used in combination with grep (each command has a --help option).
From the bundle throwing the error (with id N), imports N | grep org.apache.axiom.om will tell you which bundle it is actually importing that package from.
And approaching from the other side, exports | grep org.apache.axiom.om will list the bundles that export that package.
I'd expect you'll see more than one line from the exports and the import command will show incorrect version is being used.
You could also use java -verbose:class to see where classes are loaded from, which might show that the problematic class is loaded from a different bundle that you expected.
Related
I'm having trouble figuring out how to include/import/require mydependency.jar which MyJavaClass (within a MyJavaClass.class file) depends on. MyJavaClass contains many import statements importing classes from mydependency.jar. Everything is in the same directory.
When I run java -cp '.:mydependency.jar' MyJavaClass on the command line, I get no error and by putting some calls in main I can get it to run how I want, but when I run ruby my_ruby_file.rb with JRuby on the command line I get NoClassDefFoundError for the first class imported (which is being imported from mydependency.jar) within the MyJavaClass.class file. The stack trace for the error points to the java_import line in my_ruby_file.rb so it seems like it's not properly finding the classes imported from mydependency.jar that are included in my MyJavaClass.class file, even though it runs fine in the normal Java environment.
# contents of my_ruby_file.rb
require 'java'
require './mydependency.jar'
java_import 'MyJavaClass'
MyJavaClass.new.myJavaInstanceMethod('argument')
My $CLASSPATH environment variable was not set, which it needs to be in order for JRuby to be able to find my jar. After I ran export CLASSPATH=".:mydependency.jar" on the command line and removed the line require './mydependency.jar', it worked.
Inside ee.j2se-1.8 the package org.w3c.dom is included.
org.osgi.framework.system.packages = \
...
org.w3c.dom,\
...
org.osgi.framework.bootdelegation = \
...
org.w3c.*,\
org.xml.*,\
....
The bundle xml-apis_1.4.1.20140905-131237.jar contains the same package org.w3c.dom, but with one important class more ... ElementTraversal.class more.
So here my questions...
How can I provide the missing class inside my Equinox OSGi runtime?
You are suffering from the fact that people do not take packages seriously. We have a similar problem in the jta API. The version delivered by the VM is not identical to the version that is delivered as a special package.
The solution is to include the JAR with the extra packages on the class path where the framework resides. It looks like you're using bnd (good!) so this would look like:
-runpath: xml-apis__xml-apis;version="[1.4.1,2.0.0)"
If this had been a bundle with proper exports then you would have automatically gotten its exports as system packages. Looking at the packages in this bundle it seems all packages are already in the standard exports of the VM. However, if you have packages int his JAR that are not exported by the VM then you can add them as follows:
-runsystempackages: javax.xml.foo
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.
I am trying to add a java command to spring-actuator's ssh remote shell in a spring-boot applicaton. The spring-boot version is 1.2.3.RELEASE.
My sample command is just named 'kafka' and I tried placing it on the classpath in both /crash/commands as well as just /commands. It is never found - it doesn't show up in the help or actually work.
Is there some way to ask the remote shell to tell me what it's scanning/finding when it starts?
Things I have tried include specfically overriding shell.commandPathPatterns though the default seems like it should cover it.
My command - for testing - is very simple:
package commands;
#Usage("Kafka utility commands")
public class kafka extends BaseCommand {
#Command
public Object main(InvocationContext<ObjectName> context) {
return "it's all good";
}
}
After one hour of debugging I've found that the CRaSH remote shell looks for files with the extensions .groovy or .java within the packages are commands and crash.commands. The found files are compiled to bytecode, compiler errors are ignored.
I presume you use something like Maven. When you put your command into src/main/java then Maven will compile it as .class file and CRaSH will not find it. When you put your command into src/main/resources then Maven will not compile it and keep it as .java file instead.
The solution (which is quite odd for me) is to put your java command file into src/main/resources (package commands or crash.commands) so you have a .java source file in your target directory or JAR.
I tested it with spring-boot 1.2.1.RELEASE (crash.shell: 1.3.0) which should not be much different than 1.2.3.RELEASE (crash.shell: 1.3.1).
I'm using the HotSwap function of javassist, it requires tools.jar in classpath, so I added -cp tools.jar when start my OSGi appliction. But when I new HotSwap() in the code of one of the bundles,
java.lang.NoClassDefFoundError: com.sun.jdi.Bootstrap
was thrown. com.sun.jdi.Bootstrap is in the tools.jar and I've already added it in classpath and also I verified it worked because if not, the following code will not work:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
The Classloader of HotSwapper cannot load classcom.sun.jdi.Bootstrap? Then why it works properly in my Eclipse environment?(I added tools.jar into the libraries of Build path)
On why NoClassDefFoundError, any clue is appreciated.
You have to make sure the system bundle exports this package. For example in Felix the file jre.properties defines what packages are exported by the system bundle. Add the package com.sun.jdi there and it should work.
In eclipse this is done in config.ini. You can use org.osgi.framework.system.packages.extra= to define additional packages to export. I would rather not use boodelegation=* as it might export unwanted packages too. See:
http://www.eclipse.org/forums/index.php/m/734358/
http://wiki.eclipse.org/Equinox_Boot_Delegation
In Equinox, you can set Boot Delegation to * to gain acess to all class in bootclass, see this wiki for details. In 3.2, it was osgi.compatibility.bootdelegation=true in config.ini.