Release Notes / Version 12.2506.0
Table Of Contents
We matured the Java JShell-wrapper cm jshell. Main
purpose of the adaptations is to pave paths for using
cm jshell in automation scenarios.
For all these changes, the corresponding help texts have been updated:
Output of
cm jshell --help(see below)Inline help in
coremedianamespace (triggered bycoremedia.help()at JShell prompt)Manual section “JShell” in the Content Server manual.
Command Line Options:
The changes include new command line options:
New option
--ask-passwordto trigger interactive password prompt (previous environment variable and local system property approach still work but are considered deprecated).New option
--config <cfg>to set a custom location for.cm.jshell.properties.New option
--no-configto ignore any user configuration file.
This removes the need for workarounds to suppress reading the user configuration file (like redefininguser.home) that may have caused constant warnings to be logged while operating with JShell.New option
--no-connectto prevent auto-connect when starting thecoremedianamespace.
You can still later connect to the Content Server viacm.connect().
cm jshell --help lists these augmented options.
Also, the JShell command line options - help
and -version have been enhanced to skip obsolete
actions (like preparing the coremedia namespace)
and thus suppress irrelevant output.
The (undocumented by JShell) long-option syntax for arguments using
equals sign is now also supported (like
--startup=DEFAULT).
Error handling matured for invalid argument
usage: For options like --class-path
(original JShell option, we augment by the CoreMedia classpath)
argument pre-parsing of cm jshell has been hardened
to more align with the (wrapped) JShell tool itself especially in the
case of improper arguments usage to provide better error messages.
Increased Configuration Capabilities:
When using the user configuration file
(.cm.jshell.properties or alike) or environment
variables, they now forward all information to be available in the
Spring application context within your JShell script making use of the
coremedia namespace.
As a result, for example, properties for “Unified API Spring Boot Client Properties” are respected when establishing the connection. This includes the already known properties:
repository.urlrepository.userrepository.domainrepository.password
There is one change relevant change to be aware of, which is about
repository.password: If provided via interactive
prompt, it is now applied with highest precedence overriding all other
configuration sources. This better aligns with the expected behavior
for interactively provided information.
CoreMedia Namespace Enhancements:
The so-called coremedia namespace (represented as a
variable in your JShell script) got enhanced:
Custom properties support enhancement: Full access to all properties in
cm.jshell.propertiesvia application context (coremedia.context.getEnvironment()).
This includes the ability to use.cm.jshell.propertiesfor properties required to control the behavior of your JShell script.More log-levels: While before only
coremedia.info(...)was available, you now have more options, like, for example,coremedia.warn(...)andcoremedia.error(...). Note that for output that is not meant to be suppressed by--feedback silentoption and alike, it is still recommended to use normalSystem.outto output message, that, for example, should be read from shell scripts that invokecm jshell.Aligned return-type: As all other
connect(...)methods now also the no-arg methodcoremedia.connect()returns the establishedCapConnection(which you may also query later viacoremedia.connectionas usual).
Documentation Enhancements:
Despite mentioning the new capabilities (like the new CLI options), we applied the following changes:
Non-Writable Volumes Usage: Using
the coremedia namespace without further efforts
requires a writable volume at java.io.tmpdir. This
is not always desirable, for example, in container environments. The
approach how to prevent this (using
/save start and later
-startup) is now described in the Content Server
manual.
Security Section: Security notices
got moved to an extra section, now also referring to a relevant TOCTOU
(Time-of-Check to Time-of-Use) attack vector when using the
coremedia namespace along with an option to
mitigate the risk (which is the same as the non-writable volumes usage
mentioned above).
Upgrade Notes:
Due to the empowered configuration capabilities, a relevant change has
been applied for these environment variables and their use in the
coremedia namespace:
REPOSITORY_URLREPOSITORY_USERREPOSITORY_DOMAINREPOSITORY_PASSWORD
They are no longer duplicated in the coremedia
namespace as system properties like repository.url.
For all these properties it is best to access them now via the Spring
application context, like:
coremedia.context.getEnvironment().getProperty("repository.url")
This again requires a connection to be established via the
coremedia namespace. Otherwise, you can just access
these environment variables as usual via
System.getenv(...) in your JShell script.
Similar to that, the previous option to suppress a connection being
established right from the start (by setting
repository.url to an empty value) has been dropped,
so that you benefit from the repository.url to be
respected from all applicable property sources. If you used this
option, you should now use the --no-connect option.
coremedia namespace enhancement: If you saved the
initialization script of the coremedia namespace
before using /save -start, you may want to apply
the hardened invocation of cm.info(...) that could
have caused a NullPointerException if the
coremedia (and cm) variable
failed to initialize. You can either just save the startup scripts
again or just apply a null check for
cm prior to invoking
cm.info(...).
(CMS-27867)
