John did that one and he's very sensitive on making stuff public. What
prevents you from extending COSParser as in that example code I posted
at that time? Or am I missing something, i.e. was this for something
different?
Tilman
Am 05.10.2015 um 13:25 schrieb Allison, Timothy B.:
[switching to dev because this is entering into dev land]
Y, I did and do have it working for the 1.8.x branch. I either had it
working for the 2.0 branch before the change to SequentialSource was
made, or there’s a chance that I never got around to integrating it
into our dev wrapper for 2.0. LHappy to be back working on 2.0, though!
Is there any chance of making SequentialSource and its friends public
or possibly offering a RandomAccessRead constructor for BaseParser?
Or, is there another cleaner solution to allow subclassing of
BaseParser outside of o.a.p.pdfparser?
Plan D: move the “fixing” of metadata strings that are improperly
PDFEncoded into PDFBox.
Thank you!
Best,
Tim
*From:*Tilman Hausherr [mailto:thaush...@t-online.de]
*Sent:* Sunday, October 04, 2015 8:34 AM
*To:* us...@pdfbox.apache.org
*Subject:* Re: Subclassing BaseParser?
Am 03.10.2015 um 21:13 schrieb Allison, Timothy B.:
All,
I'm probably suffering from the same failure that led to
(https://issues.apache.org/jira/browse/TIKA-1678?focusedCommentId=14640370&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14640370),
but is it possible to subclass BaseParser outside of the oap.pdfparser package?
The actual subclassing of BaseParser is no problem, but what can I
substitute for SequentialSource, given that it and RandomAccessSource are
package-private?
But later in that issue, you wrote that "all is well", so I didn't
bother. But it is true that currently, BaseParser can only be extended
within its package, due to RandomAccessSource and SequentialSource.
There's even a netbeans warning because of that.
