xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hancock <peter.hanc...@gmail.com>
Subject Re: [VOTE] Merge Temp_URI_Unification
Date Thu, 05 Jul 2012 08:52:54 GMT
Hi Vincent, FOP Dev,

On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert <vhennebert@gmail.com> wrote:
> And BTW, what is the recommended way to get a FopFactoryConfig? The
> javadoc of buildConfig doesn’t say. I think it should.
The need to obtain an instance of a FopFactoryConfig implementation is
most probably unnecessary, however we have made it an option for two
 1 The unit test org.apache.fop.fotreetest.FOTreeTestCase uses
processing instructions in the parsed FO files to alter FopFactory
configuration.  We decided not to change this mechanism, and thus
required a way to modify the configuration.  By exposing the underling
FopFactoryConfig we were able to wrap the immutable instance in a
proxy that allows property modification.
 2 If an existing FOP client relies on the modification of the
FopFactory then there is a mechanism in place.

Modifying the FopFactory after construction is discouraged which is
why we have not advertised the practise in the javadocs or wiki.  I
have just noticed that the stativ method FopFactoryConfig
FopFactory.newInstance(FopFactoryConfig) is not marked as depricated -
I think the long term intention should be to make this method package
private, along with FopFactoryConfig.

>>> src/java/org/apache/fop/apps/io/TempResourceResolver
>>> • unless I’m mistaken there’s no way of releasing the temporary resource
>>>   once it’s no longer needed. The DefaultTempResourceResolver
>>>   implementation deleteOnExits the file but this may not be enough if
>>>   FOP is run on a server that is meant to (almost) never shut down. Or
>>>   did I miss something?
>> You missed something; this is the default implementation. This is pretty
>> much only for the CLI use-case, if users wish to define their own
>> implementation, all they have to do is implement the interface.
> OK, so presuming I want to write my own implementation that does a more
> fine-grained management of resources, how do I know that I can release
> a given resource?

This is a good point.  Currently, FOP assumes that temporary resources
become unavailable for reading once the input stream is closed.  FOP
is expected to call InputStream.close(), and this call should be used
to trigger he release of the resource, perhaps by wrapping the
underlying InputStream in an implementation FilteredInputStream that
does this cleanup. We intend to document in detail some recipes for
implementing the ResourceResolver - there is currently some further
work required for the handling of resource types (we envision that
that these will consist of something like a superset of all MIME
types) that we wish to handle first.



View raw message