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 <j...@jahewson.com> wrote:
>
>> On 29 May 2016, at 14:17, Aaron Mulder <ammul...@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-unsubscr...@pdfbox.apache.org
>> For additional commands, e-mail: users-h...@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: users-h...@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
