Versions Compared

Old Version 2

changes.mady.by.user Benjamin Armintor

Saved on

compared with

New Version 3

changes.mady.by.user Benjamin Armintor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Adding some documentation for Server impl in the app context, jaxrs, jaxws, and PEP in Spring

...

Newly Configurable Components

TripleGenerator

AttributeFinderModule (3.5)

Beginning with When objects are created (or purged) in Fedora with the Resource Index enables, Fedora uses a TripleGenerator to determine which triples should be added or deleted from the index.  In version 3.5, this component the PolicyEnforcementPoint is configurable in Spring.  Editing this configuration allows the addition of new content model-to-generator mappings for the default triple generator,  org.fcrepo.server.resourceIndex.ModelBasedTripleGenerator.

AttributeFinderModule

Beginning with version 3.5, the PolicyEnforcementPoint is configurable in Spring, allowing the configuration of new/additional AttributeFinderModules to support your XACML policy decisions.

...

, allowing the configuration of new/additional AttributeFinderModules to support your XACML policy decisions.

JAX-RS (3.6)

Fedora 3.6 uses JAX-RS to manage its REST resources, and these resources are configured in Spring via Apache CXF.  The configuration files for the JAX-RS resources are located in $FEDORA_HOME/server/config/spring/web/jaxrs/.  Resources configured here have access to beans in the applicationContext, but they do not have direct access to module beans loaded by the Server implementation (though they can request them directly from the Server).

JAX-WS (3.6)

Fedora 3.6 uses JAX-WS to manage its SOAP APIs.  The configuration for these beans is in $FEDORA_HOME/server/config/spring/web/jaxws-impl.xml. Like the JAX-RS beans, these APIs are configured in Spring via Apache CXF.  The configured beans have access to beans in the applicationContext, but must request module beans from the Server bean.

PolicyEnforcementPoint (3.6)

In Fedora 3.6, more of the XACML policy enforcement machinery is exposed to configuration via Spring.  While the PolicyEnforcementPoint implementations themselves are unlikely to be of general interest (unless you are writing an alternative authorization framework, like FESL), the exposure of the policy loading strategies as a configurable bean may be.  The default implementation, which loads all policies, is org.fcrepo.server.security.impl.SimplePolicyLoader. 

Rebuilders (3.5)

In version 3.5, the code that rebuilds Fedora's SQL database and Resource Index will look for all beans in the Spring context that implement implement org.fcrepo.server.utilities.rebuild.Rebuilder, and include them in its menu of rebuild options.

TriplestoreConnector (3.5)

Version 3.5 includes changes designed to allow more flexible configuration of TriplestoreConnectors.  There is an example of this configuration in $FEDORA_HOME/server/config/spring/README.txt.

TripleGenerator (3.5)

When objects are created (or purged) in Fedora with the Resource Index enables, Fedora uses a TripleGenerator to determine which triples should be added or deleted from the index.  In version 3.5, this component is configurable in Spring.  Editing this configuration allows the addition of new content model-to-generator mappings for the default triple generator,  org.fcrepo.server.resourceIndex.ModelBasedTripleGenerator.

Spring Application Contexts in Fedora 3.5

In Fedora 3.5, there are two "top level" application contexts: One manages the Spring components supporting the FESL authorization (AuthZ) filters, and the other is the Server context in which the Fedora modules (and other beans configured in $FEDORA_HOME/server/config/spring/ ) are managed.  These contexts are currently planned to be joined in a future version of Fedora. 

Spring Application Contexts in Fedora 3.6

In Fedora 3.6, Spring-configured web components (like the FESL authorization filters) are loaded in the same application context as the Server bean.  All the  other modules are loaded, by default, in a context managed by the Server bean (ie, a child context).