On 25/06/2020 09:16, Martynas Jusevičius wrote:
Andy,
answers inline.
On Thu, Jun 25, 2020 at 9:18 AM Andy Seaborne <a...@apache.org> wrote:
How are you using it?
Indeed, what are you using it for?
It's very old and has been replaced by StreamManager - with
compatibility (though that only applies for using jena-core on its own
... which is not a good idea and can't be guaranteed to work for all
sorts of reasons).
We have multiple levels of subclasses of FileManager that override
methods using Jersey client API and implement additional interfaces
such as ModelGetter and URIResolver, UnparsedTextURIResolver:
https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/util/jena/DataManager.java
https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/com/atomgraph/client/util/DataManager.java
Too much code, out of context.
What behaviour do they add?
Why aren't they using Locators?
Or GSP?
On 24/06/2020 22:58, Martynas Jusevičius wrote:
Hi Andy,
is FileManager already removed in the latest 3.16.0-SNAPSHOT? I've
started to get weird "No interface expected here" errors on a class
which extends FileManager.
Note the deprecations in 3.16.0-SNAPSHOT now.
It has become an interface. The implementation is still there.
It is a coordinated change between jena-core and jena-arq.
I guess this is the implementation class:
https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/util/FileManagerImpl.java
Moreover, in the StreamManager, what happened to the methods like
hasCachedModel(), addCacheModel() and most importantly loadModel()?
Did they just go away with no replacement?
The fixed-setup caching inside the FileManager was a bad idea. It is an
orthogonal issue to finding resources to access.
There are too many variations of caching setup so it is better to put
caching where the application can control it - e.g. cache size,
replacement policy etc etc.
// Application choices ...
Cache<String, Graph> cache = CacheFactory.createCache(CacheSize) ;
// and then
Graph g = cache.getOrFill(filenameOrURI, RDFDataMgr::loadGraph);
My question was not so much about caching per se but about the
FileManager mechanism for loading Models which incorporates
location-mapping and caching.
I would guess it is used by quite a few codebases by now. If that goes
away I would simply have to copy the old Jena code into our codebase.
RDFDataMgr is that functionality.
And what about the OntDocumentManager which uses FileManager
internally? What is replacing that? Ontology loading without
location-mapping and caching would be unusable.
OntDocumentManager continues to work as before.
(and it would not normally use the old FileManager except in tests - an
adapter is injected. It has been this way for years.)
