Mailing-List: contact users-help@pdfbox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@pdfbox.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Changing Font Cache File Directory
From: John Hewson <john@jahewson.com>
In-Reply-To: <CA+YcCwpjxqURqwmz0nujDrEV7PhUaN84nnwjBpZ92zcBnB-V_w@mail.gmail.com>
Date: Tue, 31 May 2016 08:27:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D847B935-2D40-4832-832F-F7E3CCA15A9F@jahewson.com>
References: <CA+YcCwqeDgQMa4Z1mNWTXBEwJ6m7zAtHp2AvVrzEEmsDCw8B+g@mail.gmail.com> <35A4D08B-4949-4E2C-AA7E-391D862D2844@jahewson.com> <CA+YcCwpjxqURqwmz0nujDrEV7PhUaN84nnwjBpZ92zcBnB-V_w@mail.gmail.com>
To: users@pdfbox.apache.org
archived-at: Tue, 31 May 2016 15:28:00 -0000


> On 30 May 2016, at 10:10, Aaron Mulder <ammulder@gmail.com> wrote:
>=20
> 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.
>=20
> 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:
>=20
> java ... ${JAVA_OPTS_EXT} ...
>=20
> 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:
>=20
> java ... ${-Dpdfbox.fontcache=3D${OPENSHIFT_DATA_DIR}} =E2=80=A6

Ok, I see. That=E2=80=99s not so great.

> And not expand the inner variable.
>=20
> 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.
>=20
> 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=E2=80=99s the best approach. Once you=E2=80=99ve =
fetched OPENSHIFT_DATA_DIR
from the environment then you can pass it to PDFBox by just setting the =
system
property via System.setProperty(=E2=80=9Cpdfbox.fontcache=E2=80=9D, =
=E2=80=9C...=E2=80=9D);

Voila.

=E2=80=94 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.
>=20
> Thanks,
>      Aaron
>=20
> On Mon, May 30, 2016 at 12:26 PM, John Hewson <john@jahewson.com> =
wrote:
>>=20
>>> On 29 May 2016, at 14:17, Aaron Mulder <ammulder@gmail.com> wrote:
>>>=20
>>> I see that the file that the font cache file is saved to a location
>>> set by a system property.
>>>=20
>>> 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.
>>>=20
>>> e.g.:
>>>=20
>>> $OPENSHIFT_DATA_DIR=3D/var/some/cryptic/dir/app-root/data/
>>>=20
>>> I can set -Dpdfbox.fontcache=3D$OPENSHIFT_DATA_DIR but once I put =
that
>>> in place, the value is fixed.
>>=20
>> Why? Isn=E2=80=99t the point in an environmental variable that its, =
well=E2=80=A6 variable?
>>=20
>>> 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.
>>=20
>> I don=E2=80=99t really understand this. You=E2=80=99re saying that =
$OPENSHIFT_DATA_DIR changes
>> but your Java program keeps running? That=E2=80=99s not going to =
work.
>>=20
>>> 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.
>>=20
>> That=E2=80=99s 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.
>>=20
>>> 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?
>>>=20
>>> Thanks,
>>>      Aaron
>>>=20
>>> 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.
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>=20


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