Hide Forgot
Link type: Superset, Source: BRMS-427, Destination: BRMS-416 securitylevel_name: Public Definition of BRMS (Standalone) authorized users was historically available in server/${CONF}/conf/props/jmx-console-users.properties. Now the file is now named soa-users.properties. If this change is intentional, and I believe it is, then the file should be named brms-users.properties. Also, we need to make sure that this change is properly documented
Also, the password is different now: jmx-console-users.properties: #admin=admin in soa-users.properties its: #admin=password
Link: Added: This issue incorporates BRMS-416
So, for Standalone, this is just a documentation issue. I'm wondering what happens to Deployable BRMS - that still uses the jmx-console properties, right?-
I'd say yes. The deployable can be used in contexts we have no control over so it doesn't make much sense to enforce a framework that might not be applicable. We would have to document the fact that the mailman user is required for deployable.
Lucas, Trevor is right. It should not be any different. We still expect users to deploy the deployable components on either EAP, EWP, SOA-P and EWS. So, they should use the same properties. I assume Docs would address this clearly. Btw, what does EWS use for the same ? Also, note, many of our customers use BRMS on other containers like Websphere and Weblogic. We dont need to get into those details and not necessarily document those scenarios. But we need to be congnizant of that fact. I am sure there are similar login module options in those products. My question is what does BRM (Guvnor) look for in that case.
comitted BRMS-P changes revision 7339
using brms.properties and brms.users
Release Notes Docs Status: Removed: Not Yet Documented Added: Not Required Writer: Added: Darrin
covered in the installation instructions