kandi X-RAY | jesterj Summary
kandi X-RAY | jesterj Summary
A new highly flexible, highly scalable document ingestion system. See the [web site] and the [documentation] for more info.
Top functions reviewed by kandi - BETA
- Main entry point
- Sets the log directory
- Loads the configuration file
- Start the internal cassandra
- Process a document found
- Sends the FTI record to the database
- Pushes the given document to the given step
- Push doc to next step if ok
- Initialize Cassandra
- Add documents to the dirty list
- Activates the database
- Exit or throw exception
- Append a log event
- Find the step with the given name
- Get the hash of the object
- Deactivates this scanner
- Ensures that the given CQL session is properly configured
- Visualizes the graph
- Create an appender
- Runs the queue
- Updates the column if missing
- Returns a set of properties for the given type
- Returns possible side effects
- Run the scanner
- Get plan
- Sets the value for the given key
jesterj Key Features
jesterj Examples and Code Snippets
Trending Discussions on jesterj
I am working towards releasing the first truly useful version of JesterJ and have hit a major snag with dependency resolution. The kind folks at Jfrog have been good enough to recognize my open source efforts with free access to Artifactory Pro and so I am using it to inspect and validate the licenses of my transitive dependencies. I use an Apache 2.0 license so I am attempting to use Apache's own standard for compliance with it's 2.0 licenses. However, one of the dependencies, Apache Tika 1.12, had some "category X" dependencies 1.12 was released around the time of some changes to that policy I think and newer versions of Tika have corrected these dependency issues.
The logical solution is to upgrade my Tika dependency. Unfortunately this has not gone well. When I upgraded Tika to 1.15 (or 1.16 now) I found that I no longer got the transitive dependencies from tika-parsers, including not getting tika-core which causes compile issues. Here's the gradle dependenccies output with 1.12:...
ANSWERAnswered 2017-Aug-09 at 13:43
In the end I had to file a bug with JFrog. They solved it for me.
It turns out that the problem was with a setting I had enabled. There is a setting to hide unauthorized resources with a 404 instead of 401 (preventing folks from fishing around to see what you have that you are not revealing). This sounded vaguely more secure so I enabled it. I believe all was fine until I also enabled the anonymous access... This combination breaks gradle's dependency resolution. JFrog support says maven (and probably also gradle) always try anonymous access first. Upon getting 404 it probably assumes the resource (the pom.xml) doesn't exist. No pom, no dependency list.
The only thing special about Tika 1.12 was that I had already loaded it up before enabling anonymous access.
So the fix was to uncheck this setting:
I am attempting to upgrade an application that uses an embedded cassandra 2.1.1 (about time!), but the application in question sets it's own security manager. Cassandra 3.11 seems to not consider this possibility and just attempts to set the security manager on it's own without any consideration that there might already be one (which fails)....
ANSWERAnswered 2017-Jun-26 at 19:24
If possible you could make sure your existing security manager allows it. Maybe something like this is causing issues since it will be applied globally to the JVM.
Alternatively you can just skip it... Its a much worse option and it may break things but you could use reflection.
No vulnerabilities reported
Reuse Trending Solutions
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page