Develop Reference

java.net.URL.getContent UnknownServiceException: no content-type

Please help me to figure out the problem:
We have 2 servers(old and new). And on the old server code works good, but on the new server this code doesn't work:
XWPFDocument doc;
try {
doc = new XWPFDocument((InputStream) this.getClass().getClassLoader().getResource(filePath).getContent());
} catch (IOException e) {
e.printStackTrace();
}
From logs:
java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1241)
at java.net.URLConnection.getContent(URLConnection.java:740)
at java.net.URL.getContent(URL.java:1081)
The File path leads to docx file which is stored inside resources of one the modules of application.
(And of course I've checked the existence of file.)
So the UrlResource is
UrlResource:jar:file:/tomcat/webapps/ourApplication/WEB-INF/lib/moduleName.jar!/internalResourseFolderStructure/file.docx
About servers:
They have a little bit different Tomcat versions:
old - Tomcat 9.0.19.0
new - Tomcat 9.0.33.0
Maybe you can get me some tips how to debug it?
(I am totally sure that it is something with server(Tomcat settings or something), but I don't know on this step how can debug such)

From URLConnection:
getContent
This method first determines the content type of the object by calling the getContentType method. If this is the first time that the application has seen that specific content type, a content handler for that content type is created.
As it's a file URL there are no HTTP headers, which is why the specific error is "no content-type". Even if the content type was available, Java by default has no idea how to turn a application/vnd.openxmlformats-officedocument.wordprocessingml.document into a Java object.
Perhaps on the old server Tomcat was set up with a MIME mapping for .docx and a ContentHandler registered to return something useful.
If what you actually want is an InputStream, then use getResourceAsStream, which will always work.

OWL Parsing From EFO

I have been trying endlessly to parse the Experimental Factor Ontology (EFO) file, but I am not able to parse it. The file I have opens fine in Protege, but I cannot seem to get it to load in Java. I have looked at a few sets of example code, and I am copying them seemingly exactly, but I do not understand why parsing fails. Here is my code:
System.setProperty("entityExpansionLimit","100000000");
OWLOntologyManager manager = OWLManager.createOWLOntologyManager();
URI uri = URI.create("file:~/efo.owl");
IRI iri = IRI.create(uri);
OWLOntology ontology = manager.loadOntologyFromOntologyDocument(iri);
And here are the errors I get:
Could not load ontology: Problem parsing
file:/~/efo.owl
Could not parse ontology. Either a suitable parser could not be found, or
parsing failed. See parser logs below for explanation.
The following parsers were tried:
Thank you, I know some similar posts have been made, but I have been unable to figure it out and am quite desperate! I can provide the stack trace if necessary, but it is quite long as there is a trace for each parser.

File URI need to be absolute for OWLAPI to parse them, but as you have a local file you can just create a File instance and pass that to IRI.create().
Alternatively pass the File instance to OWLOntologyManager::loadOntologyFromOntologyDocument()

There must be something wrong with the local, downloaded file. Loading the ontology directly from the ontology IRI worked.

Tika unable to parse after detecting mime-type

I have earlier succeeded in parsing all kinds of files with Tika by calling tika.parseToString() without setting any custom configuration or metadata. Now I have the need to filter files to parse based on mime-type.
I can find the mime-type with tika.detect(new BufferedInputStream(inputStream), new Metadata());, but when calling tika.parseToString() afterwards tika uses EmptyParser and the content-type detected is "application/octet-stream". This is default, meaning that tika is unable to find what type of file it is. I have tried to set the content type in Metadata before trying to parse the file, but this leads to org.apache.tika.exception.TikaException: TIKA-198: Illegal IOException. From what I've read this means that the file is malformed, but the same files gets parsed successfully without the check for mime-type beforehand.
Does detect() do something with the InputStream, making the parser unable to parse the files?
I'm using the same tika-instance for both checking the mime-type and parsing, version 1.13

My issue was caused by passing InputStream to the parse method directly. detect() marks and resets the stream passed, which InputStream does not support. Wrapping the InputStream into a TikaInputStream(TikaInputStream stream = TikaInputStream.get(new BufferedInputStream(inputStream));) solved the issue.

How to post a big string/json using AJAX on Play Framework 1.4.x

I have a JSON that looks more or less like this:
{"id":"id","date":"date","csvdata":"csvdata".....}
where csvdata property is a big amount of data in JSON format too.
I was trying to POST this JSON using AJAX in Play! Framework 1.4.x so I sended just like that, but when I receive the data in the server side, the csvdata looks like [object Object] and stores it in my db.
My first thought to solve this was to send the csvdata json in string format to store it like a longtext, but when I try to do this, my request fails with the following error:
413 (Request Entity Too Large)
And Play's console show me this message:
Number of request parameters 3623 is higher than maximum of 1000, aborting. Can be configured using 'http.maxParams'
I also tried to add http.maxParams=5000 in application.conf but the only result is that Play's console says nothing and in my database this field is stored as null.
Can anyone help me, or maybe suggest another solution to my problem?
Thanks you so much in advance.

Is it possible that you sent "csvdata" as an array, not a string? Each element in the array would be a separate parameter. I have sent 100KB strings using AJAX and not run into the http.maxParams limit. You can check the contents of the request body using your browser's developer tools.
If your csvdata originates as a file on the client's machine, then the easiest way to send it is as a File. Your controller action would look like:
public static void upload(String id, Date date, File csv) {
...
}
When Play! binds a parameter to the File type, it writes the contents of the parameter to a temporary file which you can read in. (This avoids running out of memory if a large file is uploaded.) The File parameter type was designed for a normal form submit, but I have used it in AJAX when the browser supported some HTML5 features (File API and Form Data).

Uploading File in DAM Programmatically using AssetManager? What MimeType should I use?

I have a form that uploads a File to a SlingServlet. The SlingSerlvet receives the file and it tries to save the file in DAM using com.day.cq.dam.api.AssetManager.(i.e. Save file in DAM programmatically)
The problem arises with MIME types. The user may upload a pdf,xls, doc etc. so the Type is not fixed. I don't know what to set the MIME type as(see the third parameter xxx) assetMgr.createAsset(newFile, is,"xxx", true);
I tried "application/octet-stream" but CQ ignores the Type saying asset ignored.
Log:
27.11.2014 18:58:48.595 *INFO* [JobHandler: /etc/workflow/instances/2014-11-27/model_879500607401687:/content/dam/videojetdocuments/videojetdocuments/offerletters/Präsentation_Dominik_Suess.pdf/jcr:content/renditions/original] com.day.cq.dam.video.FFMpegThumbnailProcess execute: asset [/content/dam/videojetdocuments/videojetdocuments/offerletters/Präsentation_Dominik_Suess.pdf] is not of a video mime type, asset ignored.
27.11.2014 18:58:48.596 *INFO* [JobHandler: /etc/workflow/instances/2014-11-27/model_879500607401687:/content/dam/videojetdocuments/videojetdocuments/offerletters/Präsentation_Dominik_Suess.pdf/jcr:content/renditions/original] com.day.cq.dam.video.FFMpegTranscodeProcess execute: asset [/content/dam/videojetdocuments/videojetdocuments/offerletters/Präsentation_Dominik_Suess.pdf] is not of a video mime type, asset ignored.
I tried this using the following link
Is there any generic MIME Type for such type of Files?

You can use the Apache Sling MimeTypeService to compute the mimetype based on an incoming filename. See also http://sling.apache.org/documentation/bundles/mime-type-support-commons-mime.html
If you don't have the filename you'll need something like the Apache Tika Detector, which analyzes the binary to try to guess its mimetype. I don't know if CQ provides such a service out of the box, but if it doesn't you could integrate it yourself.
Edit:
API that checks the MIMEType based on Magic headers Link
Helpful link for understanding the above mentioned problem Link