This introduces the RDFSource as a wrapper around an RDFServiceFactory and 2 ModelMakerFactorys.
This introduces ModelMakerUtils as a way to get the ModelMakers for context or for request.
Create implementations of RDFSource for SDB, TDB, and SPARQL.
The SDB implementation absorbs JenaPersistentDataSourceSetup and part of ConfigurationPropertiesSmokeTests,
which aren't needed unless we use SDB.
This is probably broken, without the subsequent changes.
Replace the JAR files with more current ones.
Add a one-line change to BaseInfGraph (from the Jena source), so it will work with Pellet 2.3.1
Adjust all implementations of Graph to include new methods and remove old ones.
Add annotations and generics to reduce compiler warnings.
Remove all dependencies on RDB, which is no longer supported.
This requires considerable refactoring of JenaIngestController, RDFUploadController, listModels.jsp
Refactor the ModelMaker uses
Remove VitroJenaModelMaker,
Revise VitroInterceptingModelMaker to be configurable for Config or Content models
Add debug logging code to ModelChangeImpl ChangeSetImpl, RDFServiceJena.
Add TDB support: RDFServiceFactoryTDB, RDFServiceTDB
Refactor RDFServiceJena and RDFServiceSDB so much of the code can be reused by RDFServiceTDB
Accomodate two RDFService instances - one for Configuration models and one for Content models.
Changes to RDFServiceUtils, RDFServiceSetup
Configuration models use TDB directory in Vitro home directory
Handle bulk updating:
Jena has deprecated bulk operations, and their models classes no longer use the bulk updaters
Create a VitroModelFactory to use instead of the ModelFactory, when bulk updating is required.
Create adapter classes: BulkUpdatingModel, BulkUpdatingOntModel, AbstractModelDecorator
Make the configuration model setup algorithms uniform
Combine ApplicationModelSetup and UserModelSetup into ConfigurationModelsSetup
SparqlQueryServlet was JSP-based, so delete the JSP also.
SparqlQueryController is Freemarker-based, and is a this shell around the SparqlQueryApiExecutor.
By making it a singleton, we do need an explicit Setup operation. However, it means that we can refer to the settings in client code that doesn’t have access to a request or to the ServletContext.
Other refactorings to simplify the logic or make it more scalable.
The Configuration must contain mutable information like the theme directory and the TemplateLoader. It must also be request-specific so it can have the correct Locale for language support. But we should only have one instance, so there is only one TemplateCache (alternatively, one TemplateCache per theme).
Previously, this was addressed by intercepting the Template processing and adding the request-based info to the Environment. However, this interception code needed to appear each time a Template was processed. This was sometimes overlooked, and at best introduced a bunch of duplicated code.
Instead, I extended the freemarker Configuration class to include a ThreadLocal that holds request-specific information.
Appears to work with Firefox cache and Chrome cache, except for language-dependent stuff.
Is that because it isn't configured correctly, or is it because Firefox and Chrome aren't attempting to keep more than one version of a page in their caches? Even if they do see a "Vary: Accept-Language" header?
