[
https://issues.apache.org/jira/browse/TIKA-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated TIKA-1736:
------------------------------
Description:
One file in our Common Crawl stash demonstrates a Bouncy Castle version
conflict...incompatible binaries with Jackcess and our current version of
Bouncy Castle.
java.lang.NoSuchMethodError:
org.bouncycastle.crypto.StreamCipher.processBytes([BII[BI)V
at
com.healthmarketscience.jackcess.impl.BaseCryptCodecHandler.streamDecrypt(BaseCryptCodecHandler.java:91)
at
com.healthmarketscience.jackcess.impl.BaseJetCryptCodecHandler.decodePage(BaseJetCryptCodecHandler.java:62)
at
com.healthmarketscience.jackcess.impl.PageChannel.readPage(PageChannel.java:224)
at com.healthmarketscience.jackcess.impl.UsageMap.read(UsageMap.java:130)
at
com.healthmarketscience.jackcess.impl.PageChannel.initialize(PageChannel.java:117)
at
com.healthmarketscience.jackcess.impl.DatabaseImpl.<init>(DatabaseImpl.java:516)
at
com.healthmarketscience.jackcess.impl.DatabaseImpl.open(DatabaseImpl.java:389)
at
com.healthmarketscience.jackcess.DatabaseBuilder.open(DatabaseBuilder.java:248)
at TestIt.testIt(TestIt.java:19)
A full description and test file are attached
[here|https://sourceforge.net/p/jackcessencrypt/feature-requests/2/#b65d].
There was an API change in 1.51 that causes this problem. 1.50 works with the
one test file, and 1.51 does not work. We're currently using 1.52.
It looks like POI is using 1.51 in trunk, now. According to PDFBox trunk's
build.xml, they're using 1.50, but their pom.xml has 1.51.
Two options that I see:
1) close our eyes and hope it doesn't affect too many people before Jackcess
Encrypt upgrades... perhaps add a try/catch for this one version conflict? Is
there any shade magic we can do on our end ... or (I'm assuming) would that
have to be done by Jackcess (or an upgrade, of course)?
2) downgrade our bc-prov to 1.50 (from 1.52).
Other options?
was:
One file in our Common Crawl stash demonstrates a Bouncy Castle version
conflict...incompatible binaries with Jackcess and our current version of
Bouncy Castle.
java.lang.NoSuchMethodError:
org.bouncycastle.crypto.StreamCipher.processBytes([BII[BI)V
at
com.healthmarketscience.jackcess.impl.BaseCryptCodecHandler.streamDecrypt(BaseCryptCodecHandler.java:91)
at
com.healthmarketscience.jackcess.impl.BaseJetCryptCodecHandler.decodePage(BaseJetCryptCodecHandler.java:62)
at
com.healthmarketscience.jackcess.impl.PageChannel.readPage(PageChannel.java:224)
at com.healthmarketscience.jackcess.impl.UsageMap.read(UsageMap.java:130)
at
com.healthmarketscience.jackcess.impl.PageChannel.initialize(PageChannel.java:117)
at
com.healthmarketscience.jackcess.impl.DatabaseImpl.<init>(DatabaseImpl.java:516)
at
com.healthmarketscience.jackcess.impl.DatabaseImpl.open(DatabaseImpl.java:389)
at
com.healthmarketscience.jackcess.DatabaseBuilder.open(DatabaseBuilder.java:248)
at TestIt.testIt(TestIt.java:19)
A full description and test file are attached
[here|https://sourceforge.net/p/jackcessencrypt/feature-requests/2/#b65d].
There was an API change in 1.51 that causes this problem. 1.50 works with the
one test file, and 1.51 does not work. We're currently using 1.52.
It looks like POI is using 1.51 in trunk, now. According to PDFBox trunk's
build.xml, they're using 1.50, but their pom.xml has 1.51.
Two options that I see:
1) close our eyes and hope it doesn't affect too many people before Jackcess
Encrypt upgrades perhaps add a try/catch for this one version conflict? Is
there any shade magic we can do on our end ... or (I'm assuming) would that
have to be done by Jackcess (or an upgrade, of course)?
2) downgrade our bc-prov to 1.50 (from 1.52).
Other options?
> Bouncy Castle version binary incompatibility
> --------------------------------------------
>
> Key: TIKA-1736
> URL: https://issues.apache.org/jira/browse/TIKA-1736
> Project: Tika
> Issue Type: Bug
> Reporter: Tim Allison
> Priority: Minor
>
> One file in our Common Crawl stash demonstrates a Bouncy Castle version
> conflict...incompatible binaries with Jackcess and our current version of
> Bouncy Castle.
> java.lang.NoSuchMethodError:
> org.bouncycastle.crypto.StreamCipher.processBytes([BII[BI)V
> at
> com.healthmarketscience.jackcess.impl.BaseCryptCodecHandler.streamDecrypt(BaseCryptCodecHandler.java:91)
> at
> com.healthmarketscience.jackcess.impl.BaseJetCryptCodecHandler.decodePage(BaseJetCryptCodecHandler.java:62)
> at
> com.healthmarketscience.jackcess.impl.PageChannel.readPage(PageChannel.java:224)
> at com.healthmarketscience.jackcess.impl.UsageMap.read(UsageMap.java:130)
> at
> com.healthmarketscience.jackcess.impl.PageChannel.initialize(PageChannel.java:117)
> at
> com.healthmarketscience.jackcess.impl.DatabaseImpl.<init>(DatabaseImpl.java:516)
> at
> com.healthmarketscience.jackcess.impl.DatabaseImpl.open(DatabaseImpl.java:389)
> at
> com.healthmarketscience.jackcess.DatabaseBuilder.open(DatabaseBuilder.java:248)
> at TestIt.testIt(TestIt.java:19)
> A full description and test file are attached
> [here|https://sourceforge.net/p/jackcessencrypt/feature-requests/2/#b65d].
> There was an API change in 1.51 that causes this problem. 1.50 works with
> the one test file, and 1.51 does not work. We're currently using 1.52.
> It looks like POI is using 1.51 in trunk, now. According to PDFBox trunk's
> build.xml, they're using 1.50, but their pom.xml has 1.51.
> Two options that I see:
> 1) close our eyes and hope it doesn't affect too many people before Jackcess
> Encrypt upgrades... perhaps add a try/catch for this one version conflict?
> Is there any shade magic we can do on our end ... or (I'm assuming) would
> that have to be done by Jackcess (or an upgrade, of course)?
> 2) downgrade our bc-prov to 1.50 (from 1.52).
> Other options?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
