> On 30 May 2016, at 10:10, Aaron Mulder <[email protected]> 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 <[email protected]> wrote:
>>
>>> On 29 May 2016, at 14:17, Aaron Mulder <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
