You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Aaron Mulder <am...@gmail.com> on 2016/05/29 21:17:38 UTC
Changing Font Cache File Directory
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. 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.
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.
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
Re: Changing Font Cache File Directory
Posted by John Hewson <jo...@jahewson.com>.
> On 30 May 2016, at 10:10, Aaron Mulder <am...@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 <jo...@jahewson.com> wrote:
>>
>>> On 29 May 2016, at 14:17, Aaron Mulder <am...@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
Re: Changing Font Cache File Directory
Posted by Aaron Mulder <am...@gmail.com>.
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}} ...
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?
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.
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.
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 <jo...@jahewson.com> wrote:
>
>> On 29 May 2016, at 14:17, Aaron Mulder <am...@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
Re: Changing Font Cache File Directory
Posted by John Hewson <jo...@jahewson.com>.
> On 29 May 2016, at 14:17, Aaron Mulder <am...@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