For some reason, on Java 8 in Ubuntu 18.04 running in WSL, the DS 3.x tests are failing for testGetFreePort
. It looks like the JRE or Windows are allowing Java to bind two different server sockets to the same port (port sharing), which violates the test's setup expectations.
The build should succeed with no test failures.
Full failure log
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running TestSuite
Configuring TestNG with: TestNG652Configurator
Test environment:
Java version: 1.8.0_191
Java vendor: Oracle Corporation
JVM name: OpenJDK 64-Bit Server VM
JVM version: 25.191-b12
JVM vendor: Oracle Corporation
JVM info: mixed mode
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
OS: Linux 4.4.0-17763-Microsoft amd64
Processors: 4
Max memory: 2837446656
Total memory: 192937984
How to read the progressive status info:
Test duration status: {Total min:sec. Since last status sec.}
Test count status: {# test classes # test methods # test method invocations # test failures}.
TestClass (the class that just completed)
{ 0:00 ( 0s)} { 0c 0m 0i 0f} : starting
{ 0:00 ( 0s)} { 1c 6m 6i 0f} : CertificateTestCase
{ 0:00 ( 0s)} { 2c 9m 9i 0f} : ProductInformationTest
{ 0:00 ( 0s)} { 3c 13m 21i 0f} : SetupCliTestCase
{ 0:00 ( 0s)} { 4c 16m 24i 0f} : DataConfigurationTestCase
T E S T F A I L U R E ! ! !
Failed Test: org.forgerock.opendj.server.setup.model.ListenerSettingsTestCase#testGetFreePort
Failure Cause: java.lang.AssertionError: actual value:<61728> should not be equal to:<61728>
org.fest.assertions.Fail.failure(Fail.java:228)
org.fest.assertions.Fail.fail(Fail.java:218)
org.fest.assertions.Fail.failIfEqual(Fail.java:53)
org.fest.assertions.GenericAssert.isNotEqualTo(GenericAssert.java:228)
org.fest.assertions.IntAssert.isNotEqualTo(IntAssert.java:71)
org.forgerock.opendj.server.setup.model.ListenerSettingsTestCase.testGetFreePort(ListenerSettingsTestCase.java:80)
{ 0:00 ( 0s)} { 5c 20m 28i 1f} : ListenerSettingsTestCase
{ 0:00 ( 0s)} { 6c 38m 46i 1f} : ModelTestCase
{ 0:00 ( 0s)} { 7c 43m 51i 1f} : RuntimeOptionsTestCase
The following unit tests failed:
org.forgerock.opendj.server.setup.model.ListenerSettingsTestCase#testGetFreePort
Include the ant option '-Dtest.failures=true' to rerun only the failed tests.
Wrote full test report to:
/mnt/c/Users/guypa/Documents/WrenProjects/wrends/opendj-server/target/surefire-reports/results.txt
Test classes run interleaved: 0
Final amount of memory in use: 3.0 MB
Final number of threads: 1
Tests run: 51, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.897 sec <<< FAILURE! - in TestSuite
testGetFreePort(org.forgerock.opendj.server.setup.model.ListenerSettingsTestCase) Time elapsed: 0.06 sec <<< FAILURE!
java.lang.AssertionError: actual value:<61728> should not be equal to:<61728>
at org.fest.assertions.Fail.failure(Fail.java:228)
at org.fest.assertions.Fail.fail(Fail.java:218)
at org.fest.assertions.Fail.failIfEqual(Fail.java:53)
at org.fest.assertions.GenericAssert.isNotEqualTo(GenericAssert.java:228)
at org.fest.assertions.IntAssert.isNotEqualTo(IntAssert.java:71)
at org.forgerock.opendj.server.setup.model.ListenerSettingsTestCase.testGetFreePort(ListenerSettingsTestCase.java:80)
Results :
Failed tests:
ListenerSettingsTestCase.testGetFreePort:80 actual value:<61728> should not be equal to:<61728>
Tests run: 51, Failures: 1, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.884 s
[INFO] Finished at: 2019-04-18T14:51:48Z
[INFO] Final Memory: 27M/252M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project opendj-server: There are test failures.
[ERROR]
[ERROR] Please refer to /mnt/c/Users/guypa/Documents/WrenProjects/wrends/opendj-server/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
Environment
- Product version (include GIT commit ID if using a dev build): 3.0.0 @ 3a60e66
- Operating system:
Ubuntu 18.04.1 LTS
Linux 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06 19:16:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux
- JRE version:
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
- Was instance upgraded from a previous version? If so, what version were you using before? No
Additional Notes
Looking into this issue revealed a separate issue with the way that the DS 3.x SDK looks for a free port. A separate issue for that is pending.
Summary
Connection handlers have too long and descriptive name with Connection Handler
suffix. Connection handler names are used when referencing the handler so this makes all commands unnecessarily more complex.
Connection Handler : Type : enabled : listen-port : use-ssl
-------------------------:------:---------:-------------:--------
HTTP Connection Handler : http : false : 8080 : false
JMX Connection Handler : jmx : false : 1689 : false
LDAP Connection Handler : ldap : true : 1389 : false
LDAPS Connection Handler : ldap : true : 1636 : true
LDIF Connection Handler : ldif : false : - : -
Solution You'd Like to See
I would like to remove Connection Handler
suffix and leave only the protocol name as the handler name.
Workarounds/Alternatives
None.
Additional Notes
None.
ForgeRock introduced the Persistit Data Backend (PDB) in OpenDJ 3.0.0 and deprecated it in DS 5 (i.e. OpenDJ 4.0.0).
There are multiple reasons why they abandoned it:
- ForgeRock had to fork the project because Akiban was acquired and no longer maintains it.
- Even after patches from FR, it has remaining issues that can cause deadlock in production,
- Unit tests for Persistit are painfully slow and fail if you actually run them.
- PDB is no longer needed because JE licensing is now compatible with OEM deployments of OpenDJ / Wren:DS. We still need to upgrade the JE backend – see #1.
When doing persistent search via LDAPConnectionHandler2
the result entry does not contain EntryChangeNotification
control. This causes issues in Wren:AM that uses that information in SMS component.
I have already debugged what is happening and the issue is that LDAPClientConnection2
is mapping search result entry to response using method that leads to calling incorrect overloaded constructor.
Quite obvious fix is to add overloaded method to Responses
class. However I would like to verify that it is the correct way and also possibly investigate if there is a place where we can add unit test to test this behaviour.
Affected Version: 3.0
Summary
The Wren:DS / OpenDJ Control Panel application does not appear to properly handle custom X-ENUM
syntaxes; when they are defined in the server, the Control Panel erroneously flags the schema as being incomplete and will not provide a listing of the directory or the schema.
Steps to Reproduce
- Install Wren:DS, being sure to create at least a root entry for the DC.
- Create a custom
X-ENUM
syntax (for example: https://docs.oracle.com/cd/E19476-01/821-0509/enumeration-syntax-extension.html). You can create the syntax through either the ldapmodify
CLI, or by editing 99-user.ldif
.
- Define an attribute type that uses the new
X-ENUM
syntax (reference the SunDS article mentioned earlier). You can create the syntax through either the ldapmodify
CLI, or by editing 99-user.ldif
(place it AFTER the X-ENUM
syntax definition).
- Restart Wren:DS.
- Attempt to connect to the server with Wren:DS / OpenDJ Control Panel.
Expected Results
- Control Panel connects to the server without error.
- If you browse the schema using the Control Panel application, you will find the OID of the
X-ENUM
syntax under "Attribute Syntaxes" in the "Manage Schema" window.
![image](https://user-images.githubusercontent.com/2631799/35714648-06bd4690-079c-11e8-89c8-ea336706f9b7.png)
Actual Results
- Control Panel connects but displays errors.
- The error displayed is:
Error Reading Configuration
The definition for the attribute type with OID 1.3.6.1.4.1.32473.5 declared that it should have a syntax with OID 1.3.6.1.4.1.32473.4. No such syntax is configured for use in the Directory Server
![image](https://user-images.githubusercontent.com/2631799/35714678-2fb4d644-079c-11e8-92ee-ba8ffb352dd8.png)
Additional Info
Anecdotally, it seems like this might be fixed in the 4.0 branch, according to https://bugster.forgerock.org/jira/browse/OPENDJ-3252. However, simply cherry-picking aaf3145 (the commit cited in the comments for that ticket) on to the 3.0 SDK does NOT solve the issue for 3.x. There was likely a larger re-factor of this code that addressed it.
It's not possible to build all of OpenDJ successfully in one pass. the opendj-dsml-servlet
project will fail because it can't find packages, but re-building just that package succeeds.
something is causing the classpath to be stale during the build.
Steps
- checkout Wren:DS from
sustaining/3.0.0
.
- run
mvn clean install
.
Expected
Currently
- the build fails because it cannot find several packages of generated source code:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project opendj-dsml-servlet: Compilation failure: Compilation failure:
[ERROR] opendj-dsml-servlet/src/main/java/org/opends/dsml/protocol/DSMLAddOperation.java:[37,40] package org.opends.server.protocols.ldap does not exist
- afterwards, building with
mvn clean install -pl opendj-dsml-servlet
succeeds.
Summary
Artifacts produced by Wren:DS end up with colons in their filenames, which is not an allowed character in Windows. This causes several issues, including build failure on Windows platforms.
Environment
Windows 10, JDK 8
Steps to Reproduce
- Checkout the Wren:DS project at the
3.0.0
tag.
- Run
mvn clean install
.
Expected Results
The build succeeds.
Actual Results
The build fails with an error about "negative time". This is actually because the JAR files don't get written to disk properly because their filenames contain characters not allowed in Windows.
Additional Notes
- This is like caused by the colon in the product name (i.e.
Wren:DS
).
- This may not be an issue in 3.5+ since in that version, there are new, separate Maven properties to control the lowercase product name that's used for archives.
- Even on Linux systems, this issue causes the names of files inside the Wren:DS zip file not to be correct when extracted.
Running recommended command docker run --rm --name wrends-test -p 1389:1389 -p 1636:1636 wrensecurity/wrends:latest
causes docker to crash.
opendj-setup-5163692219923348077.log
On the other hand, the docker image runs smoothly when i build it first and then run it.
docker build . -t wrends-arm:latest
docker run --rm --name wrends-test -p 1389:1389 -p 1636:1636 wrends-arm:latest
[root@einwin3-api02 wrends]# ./setup --cli
-bash: ./setup: /bin/sh^M: bad interpreter: No such file or directory
Summary
It would be good to have PBKDF2-HMAC-SHA256 and the PBKDF-HMAC-SHA512 password encoding schemes.
Solution You'd Like to See
Add these types will allow stronger password encryption & security. This seems to have been done a year ago on openidentity opendj open source project, so if the licences are compatible, it might just mean importing it here.
Workarounds/Alternatives
With openidentity opendj this works, provided you manually add the schema to schema/02-config.ldif, then these password types are available and function. The OID's need to be allocated uniquely as part of the build. Likely the DS schema && IODs got blatted / lost between major releases last year, the version just after openidentity/opendj which is described in PR #228 over there. ( the below dummy 9999* OIDs need to be made real )
This is the server schema missing on the openidentity opendj binaries :
$ diff config/schema/02-config.ldif config/schema/02-config.ldif.dist
5903,5914d5902
< objectClasses: ( 1.3.6.1.4.1.36733.2.1.2.99998
< NAME 'ds-cfg-pbkdf2-hmac-sha256-password-storage-scheme'
< SUP ds-cfg-pbkdf2-password-storage-scheme
< STRUCTURAL
< MAY ds-cfg-pbkdf2-iterations
< X-ORIGIN 'OpenDJ Directory Server' )
< objectClasses: ( 1.3.6.1.4.1.36733.2.1.2.99999
< NAME 'ds-cfg-pbkdf2-hmac-sha512-password-storage-scheme'
< SUP ds-cfg-pbkdf2-password-storage-scheme
< STRUCTURAL
< MAY ds-cfg-pbkdf2-iterations
< X-ORIGIN 'OpenDJ Directory Server' )
Additional Notes
This PR describes this change from the open identity project : OpenIdentityPlatform/OpenDJ#228
From gitter chat:
The only difference between sustaining/3.5.x and the current master are the following commits:
ad669ec93a Upgrade Wren:DS to `wrensec-parent` (2.2.0)
7765a3cb9a Remove Unused Wren Deploy Values
7dd5225a57 Fix Acct. Change Notification Package Name
b210895b0e Fix file names to conform to class names in them.
47b06874c8 Fix path to Wren:DS JAR file for Doc Generation
bef165bab8 Add note about OPENDJ-3377 as OpenIG Workaround
8bef7b5dcb OPENDJ-3377 Switch OpenDJ dependency from openig-toolkit to chf-oauth2
55da63bff3 Update 3.5.1 for WrenSec repos & info
91c3b0ba77 Add Official OpenDJ 3.5.1 Sources from Backstage
I think we can go through those and apply them if necessary.
The following will be evaluated (the main idea behind this is that if there is a critical patch, it has unit tests as well):
git show 91c3b0ba77 -I'^ *([/\*]|@Override)' -- **/src/test/** > changes.diff
When calling for status of DS i'm getting an exit code 6 as a return.
./status -ns
Server Run Status: Started
Open Connections: 0
Host Name: <hostname>
Administrative Users: cn=Directory Manager
Installation Path:
<installation path>/wrends/opendj-server-legacy/target/package/wrends
Version: Wren:DS Server 4.0.0-RC2-SNAPSHOT
Java Version: <not available> (*)
Administration Connector: Port 4444 (LDAPS)
Address:Port: --
Protocol: LDIF
State: Disabled
Address:Port: 0.0.0.0:636
Protocol: LDAPS
State: Disabled
Address:Port: 0.0.0.0:1389
Protocol: LDAP
State: Enabled
Address:Port: 0.0.0.0:1689
Protocol: JMX
State: Disabled
Address:Port: 0.0.0.0:8080
Protocol: HTTP
State: Disabled
Base DN: dc=example,dc=com
Backend ID: userRoot
Entries: <not available> (*)
Replication:
Get exit code in bash:
echo $?
6
Summary
If a background request thread encounters a RuntimeException (NullPointerException
, IllegalStateException
, etc), that thread silently dies off, leaving the main request thread blocking idefinitely on an Object.wait()
call.
Affected Version
master
(4.0.0-SNAPSHOT
)
Steps to Reproduce
One possible way to reproduce this was mentioned in my post on the FR forums:
https://forum.forgerock.com/topic/possible-bug-in-crest-when-using-clientnaming/#post-17428
A slightly easier way is to simply modify the read()
method of JsonConstantPropertyMapper
to throw a NullPointerException
inside the promsise, as follows:
Promise<JsonValue, ResourceException> read(final Context context, final Resource resource,
final JsonPointer path, final Entry entry) {
final Promise<JsonValue, ResourceException> resultPromise =
newResultPromise(new JsonValue(null));
return resultPromise.then(
new Function<JsonValue, JsonValue, ResourceException>() {
@Override
public JsonValue apply(JsonValue jsonValue) throws ResourceException {
throw new NullPointerException("Test");
}
});
}
Then run the BasicRequestsTest
.
Expected Results
A request that unexpectedly encounters a RuntimeException
while assembling a response returns an appropriate message along with a 500 Internal Server error.
Actual Results
The request hangs indefinitely. Multiple subsequent requests that each result in a runtime exception eventually cause the application server to become unresponsive because there are no more threads available in the thread pool. The only remedy is to restart the application server.
The main thread stack looks something like this:
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:502)
at org.forgerock.util.promise.PromiseImpl.await(PromiseImpl.java:618)
at org.forgerock.util.promise.PromiseImpl.getOrThrow(PromiseImpl.java:144)
at org.forgerock.json.resource.AbstractAsynchronousConnection.query(AbstractAsynchronousConnection.java:80)
at org.forgerock.json.resource.AbstractAsynchronousConnection.query(AbstractAsynchronousConnection.java:89)
at org.forgerock.opendj.rest2ldap.BasicRequestsTest.testQueryAll
The cause of this behavior appears to be that the asynchronous promise-based method Rest2LDAP uses to obtain results has no top-level exception handler on the result threads.
As a potential way to mitigate this issue, it may make sense to modify org.forgerock.json.resource.AbstractAsynchronousConnection.query()
to use a sensible timeout (5 mins?). Note that this code changed substantially between json-resource-21.0.0-alpha-6
(which is what Wren has in source control) and json-resource-21.0.0-alpha-17
(which is only available in Wren's FR archive).
This one comes from an internal feature request we're working on for Rest2LDAP.
Summary
As a developer querying a deeply nested LDAP directory of users, I would like it if nested entries could be retrieved and filtered through the Rest2LDAP interface like flat collections so that I don't have to pull the full list of entries just to get information about a single entry.
Component Affected
Rest2LDAP (OpenDJ 3.5+)
Conditions of Acceptance
The Rest2LDAP module within OpenDJ is modified as follows:
- A new option is added to the Rest2LDAP configuration file to allow collection sub-resources to support sub-tree flattening, such that nested LDAP entries are included as though they were all at the same flat level in the directory.
- A new option is added to the Rest2LDAP configuration file to allow collection sub-resources to support an optional "base" search filter that can be used to restrict what entries get returned through the sub-resource. This search filter supplements any filters provided in the request.
- Validation is added to ensure that the new sub-tree flattening option is only being used if the sub-resource is marked as read-only in the config (without this, there is no way to unambiguously map attempts to create new entries to a specific DN). Any attempt to configure a writable sub-resource with sub-tree flattening turned on must result in an error.
- Sub-resources must be modified to behave as follows:
- When the sub-resource has the new subtree flattening option toggled on: it should return all LDAP entries and sub-entries under the base DN that match both search filters provided on the query string as well as the search filter specified in the configuration for the sub-resource (i.e. it expands the search scope to
SearchScope.SUBORDINATES
).
- When the sub-resource has the new subtree flattening option toggled off or has not specified whether the option is toggled on: it should return only entries that exist directly under the base DN, excluding sub-entries (i.e. the search scope is
SearchScope.SINGLE_LEVEL
), and then apply both search filters provided on the query string as well as the search filter specified in the configuration for the sub-resource (if any).
Workarounds / Other Approaches
- Set-up a singleton resource that's mapped to a virtual static group that queries the whole sub-tree and selects the desired users from everywhere under the desired base DN. By rendering the members of the virtual static group, you can access all of the users everywhere in the subtree instead of just at the base level. Major drawback: Huge performance hit, since trying to access a single record requires pulling down the whole list of users from the server.
- Don't use subtrees -- put all users under a single flat portion of the directory (not ideal for most use cases).
- Don't use Rest2LDAP -- query LDAP directly from the application (not ideal because it requires all consumers to understand LDAP).
Summary
If a collection sub-resource defined in the Rest2LDAP endpoints JSON file is marked "isReadOnly": true
, that endpoint does not appear at all in the API descriptor returned by CREST.
Affected Version
master
(4.0.0-SNAPSHOT
)
Steps to Reproduce
- Alter the
example-v1.json
file, and add the following under resourceTypes/example-v1/subResources
(ensure you don't remove the existing users
and groups
sub-resource definitions):
"all-users": {
"type": "collection",
"dnTemplate": "ou=people,dc=example,dc=com",
"resource": "frapi:opendj:rest2ldap:user:1.0",
"namingStrategy": {
"type": "clientDnNaming",
"dnAttribute": "uid"
},
"isReadOnly": true
2, Alter the Rest2LdapJsonConfiguratorTest
, adding the line System.out.println(prettyPrint(api));
right after the parseJson(prettyPrint(api));
line.
3. Run the test.
4. Observe the console output from the test.
Expected results
The output includes the new all-users
sub-resource, even though it's read-only. Something like the attached expected.json
.
Actual results
The output omits all read-only collection sub-resources. See the attached actual.json
.
Attachments
actual vs. expected JSON.zip
Summary
Wren:DS in Docker (release 5.0.0) attempts to initialize every time, even when instance dir is already populated, which results in error on subsequent starts.
Steps To Reproduce ("Repro Steps")
- Run Wren:DS with empty volume for instance data:
docker run --rm -v wrends-data:/opt/wrends/instance wrensecurity/wrends:5.0.0
, wait for it to initialize.
- Stop Wren:DS (Ctrl+C)
- Run the same command again (re-using the now populated volume)
Alternatively, instead of using volumes, create a container, start it, stop it and start it again.
Expected Result (Behavior You Expected to See)
Wren:DS start with existing instance data which has been created during the first start.
Actual Result (Behavior You Saw)
After following repro steps above, Wren:DS fails to start with the following output:
$ docker run --rm -v wrends-data:/opt/wrends/instance wrensecurity/wrends:5.0.0
First start...
Server Already Configured
setup command-line can only be used with servers that have not yet been
configured. The current server:
- Contains data
- Has already been configured
Screenshots
N/A
Environment
- Product version (include GIT commit ID if using a dev build): Image from Docker Hub, version 5.0.0.
- Operating system: N/A (Docker)
- JRE version: N/A (Docker)
- Was instance upgraded from a previous version? If so, what version were you using before? N/A
Additional Notes
The problem lies in unset variable INSTANCE_DIR
here:
|
if [ ! -d $INSTANCE_DIR/config ]; then |
.
It is possible to move all repositories from WrenArchiver here?
And you can convert the WrenArchiver personal account to organization too.
Affected Versions
Summary
If you build the Wren:DS project on Windows, the artifacts that get produced for the "OpenIDM Account Change Notification Handler" do not contain the correct files. This leads to duplicate JAR files inside the opendj-openidm-account-change-notification-handler-3.5.1.zip
file, and a missing extensions manifest file inside the opendj-openidm-account-change-notification-handler-3.5.1.jar
file.
Environment
- Windows 10 - Version 1709 (OS Build 16299.309)
- Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T14:49:05-05:00)
Steps to Reproduce
- Build Wren:DS 3.5.1 from source on a Windows 10 machine.
- Using the ZIP file under
opendj-openidm-account-change-notification-handler/target
, attempt to follow plug-in installation instructions from ForgeRock.
Note that step 5 in FR's documentation is incorrect; the command should be:
cd /path/to/opendj/bin
./ldapmodify \
--port 389 \
--bindDN "cn=Directory Manager" \
--bindPassword "password" \
--defaultAdd \
--filename \
../config/openidm-accountchange-plugin-sample-config
Expected Results
- The plug-in can be installed successfully (even with the default, sample config).
Actual Results
- The ZIP file contains two JAR files under
lib/extensions
(opendj-openidm-account-change-notification-handler-3.5.1.jar
and opendj-openidm-account-change-notification-handler-3.5.1-shaded.jar
), when it should only contain one.
- The JAR inside the ZIP file is missing the appropriate manifest file (
org.forgerock.opendj.config.AbstractManagedObjectDefinition
).
- Attempting to use the JAR file without that manifest leads to the following error message when trying to install the plug-in:
The Directory Server is unwilling to add configuration entry cn=OpenIDM Notification Handler,cn=Account Status Notification Handlers,cn=config because one of the add listeners registered with the parent entry cn=Account Status Notification Handlers,cn=config rejected this change with the message: An error occurred while trying to initialize an instance of class org.forgerock.openidm.accountchange.OpenidmAccountStatusNotificationHandler as an account status notification handler as defined in configuration entry cn=OpenIDM Notification Handler,cn=Account Status Notification Handlers,cn=config: ClassCastException: org.forgerock.opendj.server.config.meta.AccountStatusNotificationHandlerCfgDefn$AccountStatusNotificationHandlerCfgServerImpl cannot be cast to org.forgerock.openidm.accountchange.server.OpenidmAccountStatusNotificationHandlerCfg (OpenidmAccountStatusNotificationHandler.java:221 AccountStatusNotificationHandlerConfigManager.java:360 AccountStatusNotificationHandlerConfigManager.java:225 AccountStatusNotificationHandlerConfigManager.java:48 ServerManagedObjectAddListenerAdaptor.java:66 ConfigAddListenerAdaptor.java:221 ConfigurationHandler.java:463 ConfigurationBackend.java:404 LocalBackendAddOperation.java:460 LocalBackendAddOperation.java:161 LocalBackendWorkflowElement.java:736 LocalBackendWorkflowElement.java:1051 LocalBackendWorkflowElement.java:894 AddOperationBasis.java:506 TraditionalWorkerThread.java:148)
The error results from Wren:DS not bootstrapping the configuration classes while loading the extension, which in turn means that the classes are not loaded by the time it needs to provide them to the extension. The extension tries to typecast the configuration to match the expected configuration type, but fails because Wren:DS is using only the generic configuration definition instead of the one for the plug-in.
Additional Information
The issue appears to be platform-specific. Packaging this on Ubuntu Linux 16.04 with Apache Maven 3.3.9 worked fine.
Summary
I would like Wren:DS distributions not to contain any reference to ForgeRock's commercial license.
Solution You'd Like to See
- The TXT files that contain the terms of the FR commercial license are no longer included in JAR packages for Wren:DS.
- The FR commercial license is no longer displayed on the first screen of the interactive installer. In its place, we should be displaying the CDDL instead.
Workarounds/Alternatives
Users currently have to ignore the commercial license during install, since it doesn't apply to them. This causes confusion.
When building Wren:DS in a network without public DNS available, maven fails while trying to verify the artifact signatures:
[DEBUG] (f) project = MavenProject: org.forgerock.opendj:opendj-server-parent:3.0.0 @ /home/olbohlen/git/wren/wrends/pom.xml
[DEBUG] (f) scope = test
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@704b2127
[DEBUG] (f) verifyPomFiles = true
[DEBUG] -- end configuration --
[DEBUG] The resource 'http://wrensecurity.org/trustedkeys.properties' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader.
[DEBUG] The resource 'http://wrensecurity.org/trustedkeys.properties' was not found with resourceLoader org.codehaus.plexus.resource.loader.FileResourceLoader.
[DEBUG] The resource 'http://wrensecurity.org/trustedkeys.properties' was not found with resourceLoader org.codehaus.plexus.resource.loader.ThreadContextClasspathResourceLoader.
[DEBUG] URLResourceLoader: Exception when looking for 'http://wrensecurity.org/trustedkeys.properties
java.net.UnknownHostException: wrensecurity.org
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
as a work-around, mvn -Dignore-artifact-sigs clean install
works.
Recommend Projects
-
-
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
An Open Source Machine Learning Framework for Everyone
-
The Web framework for perfectionists with deadlines.
-
A PHP framework for web artisans
-
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
Some thing interesting about web. New door for the world.
-
A server is a program made to process requests and deliver data to clients.
-
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Some thing interesting about visualization, use data art
-
Some thing interesting about game, make everyone happy.
-
Recommend Org
-
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Open source projects and samples from Microsoft.
-
Google ❤️ Open Source for everyone.
-
Alibaba Open Source for everyone
-
Data-Driven Documents codes.
-
China tencent open source team.
-