I want to elevate docx4j from 3.3.0 to a newer version.
However, there is an error caused by AbstractTableWriterModelRow has been removed.
I try to dive into release note and git log, but I got very limited info.
Could anyone provide some ideas?
In current docx4j, we have:
public class AbstractTableWriterModel extends TableModel
and in TableModel:
protected List<TableModelRow> rows;
https://github.com/plutext/docx4j/blob/master/docx4j-core/src/main/java/org/docx4j/model/table/TableModelRow.java
You can see this in use at https://github.com/plutext/docx4j/blob/master/docx4j-core/src/main/java/org/docx4j/convert/out/common/writer/AbstractTableWriter.java#L234
I guess that code replaces AbstractTableWriterModelRow.
Related
After using the sample code want to generate the HTML for the plot plot.makeFile() throws the below exception even passed a custom path still there are errors in generating the HTML file using
implementation("kscience.plotlykt:plotlykt-core:0.2.0")
Exception in thread "main" java.lang.NoSuchMethodError: java.nio.file.Path.of(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;
at kscience.plotly.PlotlyHeadersKt$systemPlotlyHeader$1.invoke(plotlyHeaders.kt:39)
at kscience.plotly.PlotlyHeadersKt$systemPlotlyHeader$1.invoke(plotlyHeaders.kt)
at kscience.plotly.HtmlKt.toHTML(html.kt:34)
at kscience.plotly.FileExportKt.makeFile(fileExport.kt:53)
at kscience.plotly.FileExportKt.makeFile$default(fileExport.kt:49)
at UndefinedKt.main(Undefined.kt:30)
at UndefinedKt.main(Undefined.kt)
The method used here is introduced in Java 11: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#of(java.lang.String,java.lang.String...)
You need to use JDK 11 or newer to run it. If I remember properly, newer versions won't even work with something below JDK 11. So just use newer JDK. If for some reason you are not able to do so, please open an issue here: https://github.com/mipt-npm/plotly.kt/issues. We can roll back to 1.8 bytecode.
guys,
I have the following case: I want during the major upgrade to preserve the version of the product being upgraded (e.g. if I am upgrading from 1.1 to 1.2, to save the value 1.1) and to run an executable passing this version as a parameter, after the install of the new product finishes. This will mean that I will call this somewhere around InstallFinalize. I found this very helpful article for my case: http://blogs.technet.com/b/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx
The problem that I experience is that I don't know and can't find an explanation on when will the property be set. When will this registry search be executed. Am I going to set this property once on the start of the upgrade or is it going to be set dynamically when the property is being invoked?
If you're using the WiX major upgrade element, this should work with AllowDowngrades set to yes. There's no need to manually try to set a version somehow. See here:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
where it says "AllowDowngrades already allows two products with the same version number to upgrade each other."
Definitely try this before trying to run code. Note that the ProductVersion property isn't "set" - it's in the MSI file and is transferred to the system from there.
In the past, I have tried to decrypt PDFs using PDFBox using the following code:
if (doc.isEncrypted()){
doc.openProtection(new StandardDecryptionMaterial(password));
doc.setAllSecurityToBeRemoved(true);
}
(Note that I don't use doc.decrypt(password) because the Javadoc for decrypt() says that openProtection() should be used instead, although why it's not just deprecated is beyond me).
Anyway, this has worked fine for quite a while. However, lately I seem to be getting the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not properly padded
at javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
<Stack trace continues with my call to openProtection()>
How can I fix this problem?
This is a known issue, which appears to have been introduced as a result of a Java update. At the time of this writing, a fix for this is in review to be included in version 1.8.8, so just upgrade to version 1.8.8 or later and this problem will go away.
I have created a POC program to exercise the JCR version handling with ModeShape on both 4.0.0.Alph4 and 3.8.0.Final. The version number is increased from 1.0, 1.1, 1.2 1.3, 1.4, and etc. Then I restored the version 1.2 and made changes to it. But I noticed that the new version number is 1.3.0 now. Should the new version number be 1.2.0 (since it is based on the original 1.2) or am I missing something from the program? Thanks!
I would have expected 1.2.1, so it looks like it might be a bug. Please report the issue in the project's bug tracker. ModeShape is an open source project, we'll likely look at the issue much more quickly if you provide a simple test case.
But what we really love is a pull-request that adds to a test class one or more test methods that replicates the problem. We can get that pull-request, run the tests (which would fail), and then fix the problem. This really saves us a lot of time, and it us know that we're fixing the exact problem you see. And you'll know that the fix will be included in the next release.
Is there any possibility to programmatically detect if a particular method is deprecated in the current version of system? Thanks
No, there is no any way to programmatically detect if a particular method is deprecated in the current version of system. The only thing you can get to know through warning message that your method is deprecated.
warnings are based on your deployment target.
set the Deployment Target to the latest version.
Do a build from the Product menu, see all the warnings.
You (and others getting here) may be trying to ask a slightly different question - how can you check to see if a deprecated method (aMethod:) of a non deprecated class (aClass) is still available at runtime? You can do that with:
if([aClass instancesRespondToSelector:#selector(aMethod:)]){
// it's still available for use
}