I'm trying to use jTwitter to get an oauth instance to twitter with my consumer key/secret and access token/secret. This is well documented in the javadoc here. I have downloaded signpost, signpost-jetty, and the jtwitter library, but after deploying and running the servlet, I get a error java.lang.NoClassDefFoundError: winterwell/jtwitter/OAuthSignpostClient Eclipse isn't complaining about the class not being there, because it is there-- I can see it in the JAR file itself, which is in my project. So, I said forget it, I'll try out OAuthScribeClient instead, but this generated a VERY SIMILAR ERROR java.lang.NoClassDefFoundError: org/scribe/oauth/Token This one confuses me even further because I have the following code in my java file, and it compiles without error or warning:
import org.scribe.oauth.Token;
Token token = new Token("myaccesstokeninfo", "accesstokensecret");
Clearly, I'm missing something very fundamental, but I am at an absolute loss as to what it may be. Thanks.
Usually "NoClassDefFoundError" happens when you forget to copy all jar-files to your "/war/WEB-INF/lib" directory, so those libs will be unavailable from server-side.
Xo4yHaMope is probably right.
If you're working from Eclipse but running using a web container, then your runtime classpath might be different from your project classpath - which can cause this error.
In order to complete Ben Winters answer what I actually did and worked is add the jar in
the libs folder within the project
see also here about folder hierarchy.
When you do this eclipse will normally add the jar to the android dependencies before launching the application. What I realise is that adding a jar in the build path will make classes available only during the build
Related
Recently I've been unable to load javascript scripts to my webworkers in react for some reason. It always responds with index.html.
My config is simply a standard create-react-app app. The screenshots are from my actual project but I have confirmed that the problem persists if I create a new project and try to initialize a minimal example.
Each ffmpeg.* file is affected. This is also not specific to ffmpeg since another library had the same issue - thankfully the initialization of that library is simpler so I was able to simply put that libraries worker-file in the public folder - and that worked.
It might be a stupid question but I'm really at my wits end here and I can't figure out how to investigate further.
Thank you <3
EDIT:
It works if I put all the files it is trying to hit in the public folder - so it has to be some kind of context issue(??) This seems like a really stupid way to go about it. It's not in a worker at the point of loading - it's the worker loader that fails to access the stuff it needs in the node_modules folder, (core script, worker script and wasm code). Whet?
I created a Karaf Instance on a Service Mix(7.0.1) and deployed my bundles into it.
The camel route is starting up properly, but always fails when it should send an email.
With the following exception:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed;
I tried several solutions i found from different sources around the web, but cannot actually fix it.
I tried commenting javax.activation out in the jre.properties file of the instance, as well as using a bundle that contains java mail and the osgi friendly version of the activation bundle in the same feature.
Could openJDK be an issue here?
Note: Everything works perfectly fine on a windows/oraclejdk environment, the exception only occurs in a linux/openjdk environment.
My issue stemed from a class loader problem after all and i fixed it by bundling javax.mail/mail/1.4.7 and org.apache.servicemix.specs.activation-api-1.1/2.8.0 in the same bundle.
I also needed to remove every occurence of javax.activation from the jre.properties and config.properties file of the child instance.
I am not sure why it ran per default on a different environment, as in theory the same classloader problems should have occured too, but that might be connected to different JREs being in use.
I'm currently following the Vespa tutorials, and ran into an issue with the HTTP API use-case. Everything works fine from the mvn install package to the vespa-deploy prepare target/application.zip.
The call to vespa-deploy activate returns normally, but the application then never gets available on localhost:8080. Looking at /opt/vespa/logs/vespa/vespa.log (in the VM) one finds the following stack trace:
Container.com.yahoo.jdisc.core.StandaloneMain error Unexpected:
exception=
java.lang.IllegalArgumentException: Could not create a component with id 'com.mydomain.demo.DemoComponent'.
Tried to load class directly, since no bundle was found for spec: sample-app-http-api-searcher.
If a bundle with the same name is installed, there is a either a version mismatch or the installed bundle's version contains a qualifier string.
at com.yahoo.osgi.OsgiImpl.resolveFromClassPath(OsgiImpl.java:48)
...
This occurred using a fresh Docker image with a clean clone of the sample-apps git repository. Preparing and activating the basic sample as well as the other http example did work seamlessly.
I checked the sources and the xml files for obvious problems but don't have any clue about what is failing and where.
target/application.zip contains
application/components/http-api-using-searcher-1.0.1-deploy.jar
application/hosts.xml
application/searchdefinitions/basic.sd
application/services.xml
And the jar itself does contain a com/mydomain/demo/DemoComponent.class file (among other things).
Potentially related issue on the github tracker: https://github.com/vespa-engine/vespa/issues/3479 I'll be posting a link to this question there as well, but I still think it's worth a SO question, at least to get some action behind the vespa tag :)
The bundle id in the application's services.xml file was wrong. Please pull the application from git and try again now. See also PR: https://github.com/vespa-engine/sample-apps/pull/18
Brief explanation: The bundle id given in the bundle="<id>" declaration in services.xml must match the 'Bundle-SymbolicName' in the bundle's manifest. When the bundle has been built with the Vespa bundle-plugin, the symbolic name is by default the same as the project's artifactId. Hence, in most cases you just have to verify that the bundle id matches the artifactId.
It seems that the latest sdk com.google.firebase:firebase-server-sdk:3.0.0 relies on creating threads for most calls, e.g., com.google.firebase.database.FirebaseDatabase.getReference
This is a problem when using GAE since it promptly throws an Exception:
servlet java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")
Are we suppoed to just use the JVM sdk (com.firebase:firebase-client-jvm) instead?
The instructions aren't so clear and it seems like the legacy website is the only one where we can get the secret. The new website gives us the .json file.
Has anyone had any success with using the new v3 version with GAE?
Yes. Just tested.
As with the 2.x SDKs, you can work around the threading limitation by using manual scaling.
While the Cloud guide on using Firebase with GAE is a bit outdated, the section on manual scaling should still be useful to help you through this.
More on ThreadManager here.
I was experiencing the same problem and discovered the cause in this blog thread.
When adding dependences, I had included appengine-java-sdk but overlooked appengine-api-1.0-sdk. Adding it eliminated the exception. The full dependencies block is:
dependencies {
appengineSdk 'com.google.appengine:appengine-java-sdk:1.9.48'
compile 'javax.servlet:servlet-api:2.5'
compile 'com.google.firebase:firebase-server-sdk:3.0.3'
compile 'com.google.appengine:appengine-api-1.0-sdk:1.9.48'
}
Include the JSON file in the "Resource Files" of appengine-web.xml.
Example:
<resource-files>
<include path="/**.xml" />
<exclude path="/feeds/**.xml" />
</resource-files>
See the link https://cloud.google.com/appengine/docs/java/config/appref#resource_files .
"The files that listed in the element are accessible by the application code using the filesystem. These files are stored on the application servers with the app as opposed to how static files are stored and served.".
Using Cmd 3.0.0.141, I have successfully generated a workspace and an Ext app in that workspace. The application builds correctly until I attempt to integrate the Bryntum Scheduler, where I encounter an error when I try to build:
"Failed to resolve dependency Sch.panel.SchedulerTree for file ExtCalendar.view.Tree"
the app is very simple at this point, uses Ext.application and follows the MVC pattern where I have a view defined "ExtCalendar.view.Tree" that extends 'Sch.panel.SchedulerTree". I also have models and stores that extend Bryntum classes as well, so I assume the compiler will trip over those as well, since it can't see the Sch namespace.
I've added a 'js' path to my app.json that points to the bryntum js file where 'Sch.panel.SchedulerTree' comes from. I've tried to run the 'refresh' command with the same results (Failed to resolve...). I've regenerated the bootstrap.js file manually using 'compile', but nothing from the Sch namespace ever gets added to it, despite the Brytum lib file being in the classpath.
What do I need to do in order to successfully run the 'build' command with libs like this?
Or, do I need to take a more granular approach using the 'compile' command?
With the help of the nice folks on the Sencha forums, I was able to resolve my build issues. The solution, for me, involved a shim. I added an external shim.js file to my index with as many //#require and //#define directives as needed in order to resolve the dependency issues.
According to the nice folks at Bryntum, once I upgrade from the free-trial version of the Bryntum Scheduler, I will be able to get rid of the shim and simply rely on the sencha.cfg classpath pointing at the Bryntum src.
Also, as an aside, the app.json file is not used in ExtJS apps, its inclusion in the generated files was a bug in build 141 of Cmd v3.
See this thread for more detail.