Toxgene can not read XML file - java

I encluntered a prblem in the execution of TOXGENE tool to generate XML file,
when I execute the command with the template file
C:\toxgene3.2\samples\catalog>toxgene catalog.tsl
template parsing Done!
Generating 200 elements in author_list: Done!
Reading List genre_lists from ./input/genres.xml"
****Error can not parse files ./input/genres.xml
org.apache.xerces.parsers.SAXParser
any suggestions to fix this error

I suffered this problem and it was caused by the jar files in the last release of Xerces-J not being what ToXgene expects. Try changing the bin/toxgene script such that $XERCES_HOME/xerces.jar on the CLASSPATH.

That's it, which was said by Sudantha, but I found a bug too.
If you is using Windows, it is necessary to edit the line 21 (set TG_CP= ...)
of the bin/toxgene.bat file. You need to remove "$" before "%" characters.
By the way, someone knows where I can to download XBench [1] generator or a ToXgene older version?
[1] https://cs.uwaterloo.ca/~tozsu/ddbms/projects/xbench/index.html
Good luck!

Related

Resolve unreadable content message in Word with Docx4J v. 3.3.3

We are processing a Word template that was created with Word 365 (Version 2202 Build 16.0.14931.20648) in Docx4J. Once the file was modified by our Java application, Word will show an error message when we open the document. The message will state that the file contains unreadable content and that Word needs to repair it. This works fine and the document will eventually open, however, the message is annoying.
I assume that the error message is related to a namespace issue (see this question). That issue was resolved with docx4j v. 8.2.9, which defines the missing namespaces properly.
However, I'm stuck with docx4j 3.3.3 and cannot update. The fix seems rather simple in the GitHub commit, so I wonder, if there is any way to resolve the issue myself. All I have in my code, is a WordprocessingMLPackage object. Can I add or append namespace definitions to that object or it's sub-properties somehow?
You can't add the namespace definitions to the WordprocessingMLPackage object.
You'll need to get the source code for 3.3.3 from https://github.com/plutext/docx4j/tree/docx4j-3.3.3 then copy the new NamespacePrefixMappings content into it, then build it. You can then deploy this new jar file.
If you wanted to try to avoid compiling the source code, you'd have 2 alternatives to try (since docx4j doesn't implement the stategy pattern there). I don't expect these to work!
One is to replace the relevant classes at runtime. For this, see How to replace classes in a running application in java ?
The other is to replace the relevant classes in your jar file, which is just a zip file.
You'd need to get the new class from docx4j 8.2.9.
Please note that sometimes, there are also changes to ContentTypeManager and ContentTypes; see for example https://github.com/plutext/docx4j/commit/d4d02d3fa6e7bf98f35d1f0520e62eb8aef06cba
That commit introduces new parts, and you'll run into problems if you update ContentTypeManager without those.
So you might be tempted to try to replace NamespacePrefixMappings in your existing jar.
But the interfaces it implements changed at https://github.com/plutext/docx4j/commit/65fb843a26b5893200a1824c04c826db2db7940c#diff-70242e2f5ec56be77fe15322526f4530b02e8eafdcb9ae16b60b2220f62e0632
See further https://github.com/plutext/docx4j/commits/VERSION_8_3_8/docx4j-core/src/main/java/org/docx4j/jaxb/NamespacePrefixMappings.java so that is going to cause you problems.
The upshot is you'll need to get the source code for 3.3.3 from https://github.com/plutext/docx4j/tree/docx4j-3.3.3 then copy the new NamespacePrefixMappings content into it (ie except the interface changes), then build it. If you do this, you may as well just deploy your new jar file.

android studio with Java compiler error: string too large to encode using UTF-8 written instead as 'STRING_TOO_LARGE'

When I clean the android project in android studio, the error happen, I have backed to previous commit or different branch, which works find couple days ago, but has this error now. I have checked this question and there is not large image or strings added for my project. STRING_TOO_LARGE String in Kothlin
I had encountered the same and fixed by clear the build cache .
I was stuck on this problem and read through this topic and no one provided a future solution. I did NOT want to revert back my Gradle. Therefore, here is the link to the updated dependencies https://github.com/stripe/stripe-android. Look for the "Android Studio (or Gradle)" section and you should see this "implementation 'com.stripe:stripe-android:8.1.0'" also you might need to add "-keep class com.stripe.android.** { *; }" if you are enabling minification in your build.gradle file.
Overall Stripe has stopped updating their own "Stripe docs" which can be found here. To give them credit their docs are helpful and should be read at least once, but be mindful that most of the docs are out date when I wrote this...
Hope this helps :)
You can use AAPT (from the android sdk/build-tools) to examine the APK and look for the offending string with the following command line (Linux):
// Linux/Mac
./aapt dump --values resources MyAppName-regular-debug.apk | grep -B 1 'STRING_TOO_LARGE'
// Windows
aapt dump --values resources MyAppName-regular-debug.apk | grep -B 1 'STRING_TOO_LARGE'
Which should point you to the culprit. In my case it was:
resource 0x7f0f015a com.example.app:string/eula: t=0x03 d=0x00000f10 (s=0x0008 r=0x00)
(string8) "STRING_TOO_LARGE"
For the time being, you can downgrade Gradle version to resolve this issue.
Use gradle 3.1 version like 3.1.3 below.
classpath 'com.android.tools.build:gradle:3.1.3'
It happens that I had an SVG too long (90Kb). So I've opened de SVG in Adobe illustrator, simplified the path to a significant number of vector less so the new icon weight 3Kb and, finally, imported again in Android Studio.
You can have a look at your Project in Android Studio and watch if your SVG drawables are larger than needed for an icon.
just use <?xml version="1.0" encoding="utf-8"?> before in your drawable file.
Example:
<?xml version="1.0" encoding="utf-8"?>
<vector
android:autoMirrored="true"
android:height="24dp"
android:viewportHeight="490.282"
android:viewportWidth="490.282"
android:width="24dp"
xmlns:android="http://schemas.android.com/apk/res/android">
<path
android:fillColor="#fff"
android:pathData="M0.043,245.197c0.6,10.1 7.3,18.6 17,21.5l179.6,54.3l6.6,123.8c0.3,4.9 3.6,9.2 8.3,10.8c1.3,0.5 2.7,0.7 4,0.7c3.5,0 6.8,-1.4 9.2,-4.1l63.5,-70.3l90,62.3c4,2.8 8.7,4.3 13.6,4.3c11.3,0 21.1,-8 23.5,-19.2l74.7,-380.7c0.9,-4.4 -0.8,-9 -4.2,-11.8c-3.5,-2.9 -8.2,-3.6 -12.4,-1.9l-459,186.8C5.143,225.897 -0.557,235.097 0.043,245.197zM226.043,414.097l-4.1,-78.1l46,31.8L226.043,414.097zM391.443,423.597l-163.8,-113.4l229.7,-222.2L391.443,423.597zM432.143,78.197l-227.1,219.7l-179.4,-54.2L432.143,78.197z"/>
</vector>
None of the above solutions worked for me. What ended up being the cause of the problem was, as it states, a String that was too large. Specifically, in my arrays.xml file under the values directory, I had some SVG arrays that were used within my app and commenting them out solved the issue.
If you know for certain you have some longer Strings somewhere in your resource directories (/res), check for any large Strings that may be lurking.
Also, this solution may help others but was not linked to in this thread.
I've been hunting for the source of STRING_TOO_LARGE errors in our build for a long time and none of these solutions worked. The reason none of them worked was that I had progaurd turned on in debug builds so when the string was replaced it didn't end up in the apk. When i disabled progaurd for debug builds, built the apk and then decompiled with apktool as suggested elsewhere
java -jar apktool_2.4.1.jar d debug.apk
and found the xml file that was in another library but progaurd stripped out before:
grep -r "STRING_TOO_LARGE" ./debug
Hope that helps someone
I found an SVG file that had a very long pathData. I commented it out and the error went away. That very same vector (when called) at runtime would cause a crash (before it was commented out).
clear your gradle in windows
gradlew cleanBuildCache
in mac
./gradlew cleanBuildCache
then building you apk if your project has problem it will be show you in the 'Messages'
view. location your problem and fix it. run agent.
The issue is caused by the AAPT/AAPT2 (Android Asset Packaging Tool) which processes your app’s resources and replaces them with the STRING_TOO_LARGE value when it finds a large string.
Find out for which one cause this problem.
To find out follow below steps:
A. Best Way:
Generate build APK
Decompile APK using any decompiler and download it.
Open it in any editor(Ex. VS Code)
Then search "STRING_TOO_LARGE" text globally and you will find affected files.
B. Another Way
The simplest way to find out, Builds an APK and analyze it. Select Build > Build Bundle(s) / APK(s) > Build APK(s). When the build completes, a confirmation notification appears, providing a link to the APK file and a link to analyze it in the APK Analyzer.
If you take a look into the the vector drawable file affected by this issue, you will find something like this:
I found this solution from Here
Just use gradlew cleanBuildCache in your Android studio terminal
In my case, i deleted a view from xml but forgot to remove its references in my kotlin code. Make sure to check this before doing anything fancy.
I found the answer from a duplicate question for Kotlin from here
Add <?xml version="1.0" encoding="utf-8"?> to the top of any resource .xml file that is missing it. (check your layout xml files, specially)
For me "gradlew cleanBuildCache" did not work, and running aapt dump --values resources MyAppName-regular-debug.apk | grep -B 1 'STRING_TOO_LARGE' did nothing either...
I ended up just deleting all my vector images since they were all pretty large and that fixed my build.. So I guess I'll have to add those back in a way that does not throw the error again..
In my case, I had renamed the package and the output-metadata.json contained the old package name. Renamed the package name there, and it was fixed.
In my case, the problem was due to the following lines in the manifest:
<activity
android:name="com.facebook.FacebookActivity"
android:configChanges="keyboard|keyboardHidden|screenLayout|screenSize|orientation"
android:label="#string/app_name"/>
Once I deleted them, the build went fine.
In my case I declared a string variable in xml using data binding without assigning a value to it. by setting value to variable problem resolved
Windows 10 Solution
Finding the file with the error: use a online decompiler if it's not a problem is some one else sees your code. Download .zip file. Open up notepad++ search -> Find in files -> STRING_TOO_LARGE -> Find all.
If the problem file is a vector asset:
Vikasdeep Singh has a great solution: avocado. Avocado will make the vector file smaller.
I had this problem and clearing the cache or updating the Gradle plugin version was not a solution
To solve the problem I had to change the name of the longest XML file to make it a bit shorter, and right after doing that the problem was solved.
In my case I use Invalidate cache and restore
go to file/Invalidate cache and restore
instead of this
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8
Replaced it with this in the gradle.properties
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=STRING_TOO_LARGE

Spring Item Writer producing file with first line prefix with non-printable characters

I recently discovered that file produced by flat file item writer is prefixed with non printable characters. I have attached screenshot below.
Project uses Spring 4.1.7 RELEASE jar with Spring batch version 2.2.5 RELEASE on java 8 platform. Any idea to resolve this?
See screenshot
[Update 03/20] This issue is resolved. Output file extension chosen was .out and for some reason when this file was created on Windows platform it had non-printable characters in the beginning of the line. When extension was changed to .txt, output was as expected. On Linux, output file with .out extension has no issues. To conclude, it was OS platform specific issue, but if someone knows actual reason behind this then please shed some light.
Without any code to look at, I'm guessing you are writing a line (probably a String) out that contains nothing but NULL values in Java...hence you get NULNULNULNUL... in the file.

Java System Level deployment Malformed deployment.config file

I am trying to install Java jre 1.8u31 from the command line. I am using system level install configuration by using the deployment.config file and deployment.properties.
I have tried the following:
deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true
I have also tried the following
deployment.system.config=file:///C:/Windows/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true
I have swapped the entries around in hopes of getting a better error describing what I am doing wrong. I have also made the first line blank in the deployment.config file. I have googled and tried all examples I could find online. In all the cases, I am being presented a dialog box with an error that states the deployment.config file's line 1 is malformed.
Any suggestions would be greatly appreciated.
Russ
I have tried all of these formats:
The path you have given should be in below format
deployment.system.config=file:/C:/Windows/Sun/Java/Deployment/deployment.proper‌​ties
I got the install to work correctly. What I did was put the deployment.config file in the C:\Windows\Sun\Java\Deployment directory. The property in the file was setup as so:
deployment.system.config=file\:C\:\\Sup\\Java\\UPGRADE\\Deployment\\deployment.properties
The exceptionlist file was in the same directory as the deployment.properties file.

nokia error code 217 - jar manifest end of line

I have developed a J2ME application with J2ME Polish. Nokia now validate contents that will be submitted to the store, the challenge is that during validation of my JAR and JAD files, I get Error 217 - The JAR manifest does not end with a new line
I checked my JAR manifest and finds out that it is ending with a new line. Is anyone having any suggestions or solutions?
Double check that there are no invisible characters like whitespace or tab at the last line of the manifest.
If manifest has a newline indeed, error message apparently means a bug in this Nokia device.
Still, it is possible that your manifest has something wrong and that Nokia only used incorrect message to indicate some other problem in it. Getting messages like this, make sure that your manifest conforms to respective sections of JAR file Specification (available online), particularly:
Manifest Specification
Notes on Manifest and Signature Files
First I'd check is that manifest lines do not exceed "72 bytes (not characters), in its UTF8-encoded form".
Another thing worth trying is to experiment with various styles of line endings of those specified: CR LF | LF | CR. In your IDE / build there could be a setting to manage that, look for something called like "DOS / Unix / Mac line breaks". Specification states that all these are OK, but you better account for a chance of bug in the device not being able to recognize particular style line breaks.
Also consider checking / asking at Nokia forums for this might be a known issue with particular device.
Finally got this, i used the jar tool provided by the java sdk to extract the midlet from the jar file like this:
jar xf myjarfile.jar META-INF/MANIFEST.MF
then edited the file in a text editor and updated the manifest in the jar file
jar umf META-INF/MANIFEST.MF myjarfile.jar
Thanks for suggestions guys.
optionally you can open your jar file using winrar software then you can access the manifest from the META - INI file.from this you can edit it using the text editor after which you can save CAUTION:after saving note that the size is going to change so make sure you check the size of the jar after you have edited , by right clicking then view properties.check the size then change it accordingly to jad file by opening your jad file in a text editor
thats it:-0

Categories

Resources