@@ -4,6 +4,39 @@ All notable changes to this project are documented in this file following the [K
Issues reported on [GitHub](https://github.com/authzforce/core/issues) are referenced in the form of `[GH-N]`, where N is the issue number. Issues reported on [OW2](https://jira.ow2.org/browse/AUTHZFORCE/) are mentioned in the form of `[OW2-N]`, where N is the issue number.
- Replaced attribute `badRequestStatusDetailLevel` with `clientRequestErrorVerbosityLevel`
- Replaced attributes `requestFilter` and `resultFilter` with element `ioProcChain` of new type `InOutProcChain` defining a pair of request preprocessor (ex-requestFilter) and result postprocessor (ex-resultFilter)
- Added `maxIntegerValue` attribute allowing to define the expected max integer value to be handled by the PDP engine during evaluation, based on which the engine selects the best Java representation among several (BigInteger, Long, Integer) for memory and CPU usage optimization
- Renamed PDP engine interfaces and base implementations:
*`(Base)DatatypeFactory(Registry)` -> `(Base)AttributeValueFactory(Registry)` (using new `AttributeDatatype` subclass of `Datatype`)
- Core PDP engine made agnostic of decision request/response formats, and extensible through `PdpEngineInoutAdapter` interface, and more specifically `DecisionRequestPreprocessor` and `DecisionResultPostprocessor` interfaces, in order to support new types of input/output (SerDes) formats (native implementations provided for XACML 3.0/XML - core specification - using JAXB API, and XACML/JSON - JSON Profile of XACML 3.0)
- Identifiers of native PDP requestFilter/resultFilter (now requestPreproc/resultPostproc) extensions:
-*...:request-filter:...* renamed to *...:request-preproc:xacml-xml:...*
-*...result-filter:...* renamed to *...:result-postproc:xacml-xml:...*
- Replaced `JaxbXacmlUtils` utility class with `Xacml3JaxbHelper` (in authzforce-ce-xacml-model dependency)
- Changed naming convention for Java class names with acronym(s) (only first letter should be uppercase), e.g. PolicyPOJO -> PolicyPojo
### Added
- Module `pdp-io-xacml-json` - XACML JSON Profile implementation: provides PDP extensions for processing (request/result pre/postprocessors) JSON input/output formats defined by JSON Profile of
XACML 3.0, and adapting to the PDP engine API; also provides automatic conversion of OASIS XACML 3.0/XML conformance test to XACML/JSON format (JSON Profile of XACML 3.0) with XSLT.
- Module `pdp-cli`: provides a PDP command-line interface and produces an executable jar allowing to test the PDP engine on the command line
- PDP engine I/O adapter extension mechanism for supporting new input/output formats of decision requests/responses
-`PdpEngineAdapters` utility class to help instantiate PDP engines supporting specific input/output formats
-`PpEngineConfiguration` utility class to help instantiate a PDP engine from a PDP XML configuration file (valid against PDP configuration XSD)
## 9.1.0
### Changed
- MongoDBRefPolicyProviderModule class: removed useless method already implemented by super class BaseStaticRefPolicyProviderModule.
*[Google Java Style Guide](https://google.github.io/styleguide/javaguide.html), except braces must follow the Allman style instead of K & R style;
**Effective Java, Second Edition*, by Joshua Bloch;
*[Oracle Secure Coding Guidelines for Java SE](http://www.oracle.com/technetwork/java/seccodeguide-139067.html).
### Testing
For every new major functionality, there must be unit tests added to some unit test class that is part of the automated test suite of [pdp-engine's MainTest.java](pdp-engine/src/test/java/org/ow2/authzforce/core/pdp/impl/test/MainTest.java). If the functionality has any impact on XACML - any Request/Response/Policy(Set) element - processing and/or change XACML standard conformance in anyway, make sure you add relevant integration and/or conformance tests to the test suite run by [pdp-testutils's MainTest.java](pdp-testutils/src/test/java/org/ow2/authzforce/core/pdp/testutil/test/MainTest.java).
### Dependency management
1. No SNAPSHOT dependencies on "develop" and obviously "master" branches
### Releasing
1. From the develop branch, prepare a release (example using a HTTP proxy):
If, after deployment, the command does not succeed because of some issue with the branches. Fix the issue, then re-run the same command but with 'noDeploy' option set to true to avoid re-deployment:
<!-- Consider combining with Red Hat Victims and OSS Index. More info on Victims vs. Dependency-check: https://bugzilla.redhat.com/show_bug.cgi?id=1388712 -->
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<configuration>
<cveValidForHours>24</cveValidForHours>
<!-- The plugin has numerous issues with version matching, which triggers false positives so we need a "suppresion" file for those. More info: https://github.com/jeremylong/DependencyCheck/issues -->
<!-- This execution of surefire is overwritten by a default one unless we specify a different version in pluginManagement. -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skipAfterFailureCount>1</skipAfterFailureCount>
<!-- redirectTestOutputToFile: set this to 'true' to redirect the unit test standard output to a file (found in reportsDirectory/testName-output.txt) -->
<!-- verbosity level from 0 to 10 (10 is the most detailed), or -1 for debug More info: http://maven.apache.org/surefire/maven-surefire-plugin/examples/testng.html -->
