JXTA Practical jxta II examples ....exception when NetManager.startNetwork(); is executed - p2p

I have been trying to run examples of practical jxta ii but iam getting this exception
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/netty/channel/ChannelFactory
this exception is encountered when this line is executed
PeerGroup TheNetPeerGroup = NetManager.startNetwork();
I have used jxse-2.6 to run the examples...i hve followed all the steps mentioned in the book...
Where can i find jxse-2.7.jar file ...couldnot find it...??
I am running the examples in netbeans and i have included the netty-3.1.5.GA.jar in the library

You need to add netty in your classpath. Get it from netty.io website.

Related

Error in submitting the es-injector.flux topology

I have setup the stormcrawler project using this medium story https://medium.com/analytics-vidhya/web-scraping-and-indexing-with-stormcrawler-and-elasticsearch-a105cb9c02ca, but when I tried to submit the es-injector.flux, then I recevied this error:
Exception in thread "main" java.lang.IllegalArgumentException: Couldn't find a suitable
constructor for class 'com.digitalpebble.stormcrawler.util.StringTabScheme' with
arguments '[DISCOVERED]'.
at org.apache.storm.flux.FluxBuilder.buildObject(FluxBuilder.java:358)
at org.apache.storm.flux.FluxBuilder.buildComponents(FluxBuilder.java:421)
at org.apache.storm.flux.FluxBuilder.buildTopology(FluxBuilder.java:101)
at org.apache.storm.flux.Flux.runCli(Flux.java:158)
at org.apache.storm.flux.Flux.main(Flux.java:103)
The command that I run is:
storm jar target/project-1.0-SNAPSHOT.jar org.apache.storm.flux.Flux --local es-
injector.flux
Can someone please tell me what does it mean and how can I get rid of this error?
The latest ES tutorial is probably a better starting point, I'd recommend that you use it instead.

create exception when python command generates a program.exe has stopped working type error

I am facing a problem with a program i am developing in Python 3.6 under Windows 10.
One particular command generates an unknown error, windows throws a 'program.exe has stopped working' message and the program exits.
The command is a 3d-model loader that is part of another python package (Panda3D). The crash is always associated with this command (and more particularly with a specific dll of the loader) and a particular file that it tries to open.
Since i cannot locate and therefore solve the faults in the dll (probably there is a bug there) i would like to just pass the problematic file and continue to the next one. But since python exits and i do not know the error type, the typical try, except does not work.
So, i would like to know if there is a way to predict this type of behavior in my code and prevent the program from exiting.
Many thanks for any help.
The pop-up "Program.exe has stopped working." can be caused by a variety of things and therefor there is no "one size fits all" type solution. But if you're certain that your problem is cause by a specific line of code you can always try something along the lines of :
try:
loader.loadModel("c/path/to/your/file")
except Exception as e:
print(e.message, e.args)
# your error-handling code here
Make sure the file path that you're giving to loadModel respects the following :
# WRONG:
loader.loadModel("c:\\Program Files\\My Game\\Models\\Model1.egg")
# RIGHT:
loader.loadModel("/c/Program Files/My Game/Models/Model1.egg")
Source : pandas3d official documentation

While running UploadJars utility in OIM following exception is coming

While running UploadJars utility after giving all the parameters, utility is failing with following exception:
Logging configuration class "oracle.core.ojdl.logging.LoggingConfiguration" failed
java.lang.ClassNotFoundException: oracle.core.ojdl.logging.LoggingConfiguration
Error occurred in performing the operation:
Exception in thread "main" java.lang.NullPointerException
at oracle.iam.platformservice.utils.JarUploadUtility.main(JarUploadUtility.java:232)
Any help will be appreciated :)
We had the same problem.
We added
ORACLE_COMMON/modules/oracle.odl_11.1.1/ojdl.jar
(where ORACLE_COMMON is your oracle_common directory) to the start of our CLASSPATH and the error went away.
I think UploadJars.sh worked anyway, it was just writing out a problem with logging what it was doing.
btw, Note you might need to use UpdateJars.sh if an earlier version of the file already exists. You can check if the upload/update was successful by looking at the date in OIMHOME_JARS.UPDATED_ON.

Spark 1.4 image for Google Cloud?

With bdutil, the latest version of tarball I can find is on spark 1.3.1:
gs://spark-dist/spark-1.3.1-bin-hadoop2.6.tgz
There are a few new DataFrame features in Spark 1.4 that I want to use. Any chance the Spark 1.4 image be available for bdutil, or any workaround?
UPDATE:
Following the suggestion from Angus Davis, I downloaded and pointed to spark-1.4.1-bin-hadoop2.6.tgz, the deployment went well; however, run into error when calling SqlContext.parquetFile(). I cannot explain why this exception is possible, GoogleHadoopFileSystem should be a subclass of org.apache.hadoop.fs.FileSystem. Will continue investigate on this.
Caused by: java.lang.ClassCastException: com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystem cannot be cast to org.apache.hadoop.fs.FileSystem
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2595)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:91)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2630)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2612)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:169)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:354)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296)
at org.apache.hadoop.hive.metastore.Warehouse.getFs(Warehouse.java:112)
at org.apache.hadoop.hive.metastore.Warehouse.getDnsPath(Warehouse.java:144)
at org.apache.hadoop.hive.metastore.Warehouse.getWhRoot(Warehouse.java:159)
at org.apache.hadoop.hive.metastore.Warehouse.getDefaultDatabasePath(Warehouse.java:177)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB_core(HiveMetaStore.java:504)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB(HiveMetaStore.java:523)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.init(HiveMetaStore.java:397)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.<init>(HiveMetaStore.java:356)
at org.apache.hadoop.hive.metastore.RetryingHMSHandler.<init>(RetryingHMSHandler.java:54)
at org.apache.hadoop.hive.metastore.RetryingHMSHandler.getProxy(RetryingHMSHandler.java:59)
at org.apache.hadoop.hive.metastore.HiveMetaStore.newHMSHandler(HiveMetaStore.java:4944)
at org.apache.hadoop.hive.metastore.HiveMetaStoreClient.<init>(HiveMetaStoreClient.java:171)
Asked a separate question about the exception here
UPDATE:
The error turned out to be a Spark defect; resolution/workaround provided in the above question.
Thanks!
Haiying
If a local workaround is acceptable, you can copy the spark-1.4.1-bin-hadoop2.6.tgz from an apache mirror into a bucket that you control. You can then edit extensions/spark/spark-env.sh and change SPARK_HADOOP2_TARBALL_URI='<your copy of spark 1.4.1>' (make certain that the service account running your VMs has permission to read the tarball).
Note that I haven't done any testing to see if Spark 1.4.1 works out of the box right now, but I'd be interested in hearing your experience if you decide to give it a go.

log4j truncates the stacktrace

I am trying to track down a problem with GWT. I get an error which I want to track down to the source but log4j truncates the stacktrace by indicating something like "... 26 more" hence I cannot determine the exact location for the problem. I tried finding out if there is anyway to prevent that truncation but have been unable to find any option that will accomplish that. Is this truncation a configurable feature?
I am running Tomcat 6.0.31, Spring 3.0 (for backend), GWT 2.1.0.
Thanks
It isn't log4j truncating the stack trace, it's standard Java. And it's actually only making the trace more readable because those lines that were omitted were already output by the 'enclosing' exception. See Throwable javadoc.

Resources