I need to dump data from Nutch 2.3 into a WARC file. However, i couldn't find the necessary module. Nutch 1.x had this capability. I would like to know the proper way to do it.
As you said, at the moment the WARC exporter module is not yet ported to the 2.x branch of Nutch, nevertheless porting the https://github.com/apache/nutch/blob/master/src/java/org/apache/nutch/tools/warc/WARCExporter.java module shoudln't be that hard. As a general rule the 1.x branch of Nutch still is more used and better equiped than the 2.x branch (at least for now).
Related
I am experiencing difficulties to get started using StormCrawler using the StormCrawler+ElasticSearch archetype. On the StormCrawler website, I see two versions, namely 1x and 2x. Similarly, Apache Storm comes in version 1 and 2.
Should I install StormCrawler using the version 1x or 2x?
What version of JDK does StormCrawler require? Is there a need to use Oracle JDK or can the OpenJDK be used as well?
I want to use StormCrawler to identify and process images and documents. At what place in the topology can these tasks best be added?
Update: According to the following URL (Storm Crawler with Java 11), StormCrawler 2 is advised. What StormCrawler+ElasticSearch archetype should be used when using StormCrawler 2?
SC 1.x is stable and the current version, 2.x is less tested but will be the main version at some point.
The thread mentioned in the question does not advise you to use SC2 as such, it mentions that you should use it if you need Java 11. If you are on Java 8, then you can use whichever version you want.
SC works fine with openjdk.
As for question #3, it depends what you want to do. Can you please elaborate?
how to monitor/log slow running queries in Apache Cassandra 2.2.X version without using any external monitoring tools? Is there is any parameter that we can set in YAML to log slow running queries? or any other approach?
Also in CASSANDRA-12403, i see they added parameter "slow_query_log_timeout_in_ms: 500" for this purpose. Can we add this parameter in Cassandra 2.2.X version's Cassandra.YAML file? or do we need to apply this patch for 2.2.X version in order to make it work?
Its a feature in a newer version, you can upgrade or apply the patch and go off of a custom build. In 2.2.x theres no support to do it by itself.
Its a bit of a long shot but you might be able to get https://github.com/smartcat-labs/cassandra-diagnostics with https://github.com/smartcat-labs/cassandra-diagnostics/blob/dev/cassandra-diagnostics-core/COREMODULES.md#slow-query-module to work. It also only supports 2.1 and 3.0 though, I dont see 2.2 there.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
Would anyone have any insight on getting icefaces 1.8.2 to run in Glassfish 3? I have read that a version of Glassfish exists (1.8.2a) that would work but I cannot find it.
Thanks
At the very least, you've have to swap out the JSF libraries from JSF 2 (which is what is supplied as part of GF3) to JSF 1.2 (which is what ICEfaces 1.8 uses). This might be a bit fiddly.
It looks like you need the 1.8.2a release, which has some fixes to enable this, as well. It also looks like it's not freely-downloadable. If you have a ICEfacesEE subscription, you can get it, but it's not open source. Unless this has changed. Version 1.8 of ICEfaces is fairly old now, and they don't list anything before v2 on their pages.
Good luck
I've got a large code base that currently runs on JSF 1.1 on embedded Jetty 5.1.14 server (Servlet 2.4). I've managed to get a JSF 2.0.9 app running on this version of Jetty even though I'd expected to require servlet 2.5, and I add EL 2.1.2 & the JSF jar to WEB-INF/lib. This works on a jetty config that excludes JSF 1.1.
The production environment consists of a large number of war and jar files on a single server instance.
JSF 1.1 is currently in the server ext/lib folder, and in a single war file I'd like to include the JSF 2 jar in the WEB-INF/lib. This is not possible as the server JSF version will load first and cause classpath pollution.
However would it be possible to eliminate the JSF 1.1 jar loading in just the one war file with a custom classloader? The documentation seems to cater for the case of adding paths to the classpath rather than excluding things. I wasn't clear whether it's loaded in the context of the server as a whole or just the war.
A little more information: Another potential solution is to simply upgrade to Jetty 8 and JSF 2.1+. Apart from convincing management that this is a good idea, we use an old WebMethods7 version, this has a graphical layout tool that produces some XML that is translated by a Component Application Framework, which uses the JSF APIs to generate content (so only a very few JSPs). This would simply be a case of seeing if it works, and if not having a total rethink because of the need to keep supporting this WebMethods "code".
The main goal here is to ultimately run up to date software although not necessarily in one step.
Jetty5 is incredibly old at this point and I would recommend working on the update to jetty8, or waiting a couple of months and making the jump to jetty9 which we are currently releasing milestones for. Changes in the newer jvm's since then alone are enough reason to update your jetty container.
I don't know if this approach was supported in jetty5 or not, but in jetty6 we have ability on the webapp context to modify the classes that are exposed to the context via system and server classes. If those hooks exists then you should be able to tweak that specific context to not expose the classes in the jar in ext/lib.