pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hewson <j...@jahewson.com>
Subject Re: Changing Font Cache File Directory
Date Tue, 31 May 2016 15:27:51 GMT

> On 30 May 2016, at 10:10, Aaron Mulder <ammulder@gmail.com> wrote:
> 
> Sorry, the environment there seems a little funky.  For instance, your
> home directory is not writable, only the subdirectory identified by
> $OPENSHIFT_DATA_DIR.  So the PDFBox fallback logic of writing to your
> home dir fails too.
> 
> Each time I (re)start the server, it reads the current set of
> environment variables and system properties.  However, the only way I
> can set a system property is to put a value into a file, which is read
> into a shell variable, and substituted into the command line used to
> start the server.  If I put the name of the environment variable into
> the file that will become a system property, it's not expanded.  The
> startup command looks something like this:
> 
> java ... ${JAVA_OPTS_EXT} ...
> 
> Where the value to put in JAVA_OPTS_EXT is read from a file.  Now if
> that JAVA_OPTS_EXT value contains ${OPENSHIFT_DATA_DIR}, the
> ${OPENSHIFT_DATA_DIR} is not expanded because the shell doesn't seem
> to recursively expand variables within variables -- it would come out
> conceptually something like this:
> 
> java ... ${-Dpdfbox.fontcache=${OPENSHIFT_DATA_DIR}} …

Ok, I see. That’s not so great.

> And not expand the inner variable.
> 
> So I can run "echo $OPENSHIFT_DATA_DIR > the-file" to update the value
> for JAVA_OPTS_EXT in the file, but I have to know to do that.  It
> doesn't happen every time the server is restarted.
> 
> My fear is that for whatever reason, the OpenShift admins decide to
> move my VM around, so they shut down the server, change
> OPENSHIFT_DATA_DIR, and start the server up again -- a process that is
> supposed to be pretty much without side effects.  But because the file
> with my JAVA_OPTS_EXT definition wasn't changed, it still has the old
> value, and then the font cache is neither readable nor writable to
> PDFBox.  I think it would even be a subtle bug because it would just
> add time and memory to every "first time PDFBox is used" in a given
> run of the server as it rebuilds the font cache on every startup,
> right?

Right.

> As for the timing, I guess I was confused because PDFBox doesn't emit
> the message about building the font cache at JVM startup, only when
> you go to use PDFBox.  But maybe that's just when the relevant classes
> were first loaded.

Yes, exactly.

> I'm not really sure what to do.  I don't think I can alter the server
> startup script.  My Spring config files have a decent amount of
> ${OPENSHIFT_DATA_DIR}/foo/bar in them, or I can
> System.getenv("OPENSHIFT_DATA_DIR"), so I can arrange for the right
> value to get into the JVM, I just am having trouble figuring out how
> to get PDFBox to be aware of it.

Yeah I think that’s the best approach. Once you’ve fetched OPENSHIFT_DATA_DIR
from the environment then you can pass it to PDFBox by just setting the system
property via System.setProperty(“pdfbox.fontcache”, “...”);

Voila.

— John

> I suppose if I have to I could update just that one class file and
> patch the JAR, but that doesn't seem like a vastly better solution
> than "keep your fingers crossed".  Might be as good to just hardcode
> the current OPENSHIFT_DATA_DIR into some class and have it e-mail me
> if that doesn't match System.getenv("OPENSHIFT_DATA_DIR") so I know to
> go update the system property.
> 
> Thanks,
>      Aaron
> 
> On Mon, May 30, 2016 at 12:26 PM, John Hewson <john@jahewson.com> wrote:
>> 
>>> On 29 May 2016, at 14:17, Aaron Mulder <ammulder@gmail.com> wrote:
>>> 
>>> I see that the file that the font cache file is saved to a location
>>> set by a system property.
>>> 
>>> I'm deploying my PDFBox app to OpenShift.  The font cache directory
>>> should be set to the value of an environment variable in that
>>> environment (or some offset from the path in the env var).  And, while
>>> I can set the system property to the environment variable, it's a
>>> one-time administrative action to change system properties, not
>>> something that happens on every deployment.
>>> 
>>> e.g.:
>>> 
>>> $OPENSHIFT_DATA_DIR=/var/some/cryptic/dir/app-root/data/
>>> 
>>> I can set -Dpdfbox.fontcache=$OPENSHIFT_DATA_DIR but once I put that
>>> in place, the value is fixed.
>> 
>> Why? Isn’t the point in an environmental variable that its, well… variable?
>> 
>>> If $OPENSHIFT_DATA_DIR later changes
>>> because they shuffle my VM or something, then the system property will
>>> still refer to the old location until I figure out there's a problem
>>> and go reset the system property.
>> 
>> I don’t really understand this. You’re saying that $OPENSHIFT_DATA_DIR changes
>> but your Java program keeps running? That’s not going to work.
>> 
>>> Long story short, I'd like some way to programmatically set the font
>>> cache directory, so I can run something like
>>> FileSystemFontProvider.setDiskCacheFile(...) before I do anything else
>>> with PDFBox.
>> 
>> That’s not going to be possible, firstly because FileSystemFontProvider is not
>> public and secondly because it relies on a static initializer, which does not
>> allow for the opportunity to call any methods beforehand.
>> 
>>> Would you accept a patch to add that to FileSystemFontProvider?  Add a
>>> property that defaults to null, and if set, its value takes priority
>>> over the current logic to calculate the cache file?
>>> 
>>> Thanks,
>>>      Aaron
>>> 
>>> P.S. Or, of course, if you want it to work automagically in OpenShift,
>>> the patch could be to check for env var OPENSHIFT_DATA_DIR and put the
>>> cache file there if that variable is defined.
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org


Mime
View raw message