5.1.1.Final release
jadelkhoury
released this
29 Jun 19:33
·
221 commits
to master
since this release
[5.1.1.Final]
This content is a duplicate of the Change Log
Added
- The OSLC Config domain model was expanded.
- An
OSLC4JUtils::isWellFormed
method was added to help check the validity of strings as valid XML literals when the inputs are supposed to be used on properties of therdf:XMLLiteral
type. Warning: this method is quite slow, especially if a resource contains 10s or 100s of such values. We recommend to use this method only in tests.
Changed
- Consistently save Credentials, Connector & admin_session values under session attribute, in the oauth-core AbstractAdapterCredentialsFilter class.
- Apache Jena depency was updated from 4.5.0 to 4.8.0 due to CVE-2023-22665.
- OSLC Domains are based on latest LyoDesigner, and for
lyoVersion="5.0.1-SNAPSHOT"
. - The
oslc4j-core
artifact (grouporg.eclipse.lyo.oslc4j.core
) was refactored, extracting some essential model classes intolyo-core-model
and legacy Wink-dependent code intooslc4j-core-wink
. This allows to eliminate all dependencies on Wink. Also, applications that don't needoslc4j-core
, can eliminate the dependency on JAX-RS by replacing your dependency onoslc4j-core
withlyo-core-model
. No breaking changes were made. JenaModelHelper
was moved tooslc4j-core
, whileJsonHelper
was moved tooslc4j-core-wink
. No breaking changes were made, old package names were kept. See #292OSLC4JConstants
andOSLC4JUtils
were extracted fromoslc4j-core
toorg.eclipse.lyo.oslc4j.server:lyo-core-settings
as they are only useful in the JAX-RS server-side scenarios. No breaking changes were made, becauseoslc4j-core
still depends on the newly introduced artifact.
Deprecated
- The newly refactored artifact
oslc4j-core-wink
is deprecated.
Removed
Fixed
- A regression is fixed where
org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlProvider
could try to unmarshal an Array or a Collection, which would interfere with the application of the suitable providers when the RDF input is correct. - PR 260 fixed the bug in
ResourcePackages.getMostConcreteClassOf
that could trigger the error "Multiple classes, not in the same inheritance tree, are annotated to map the same RDF:type".