[ https://issues.jboss.org/browse/WFLY-12301?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFLY-12301: ----------------------------------- I was able to reproduce this locally and found the following: * When the caller principal for the EJB2 bean is correct, the corresponding {{EJBComponentDescription}} always has {{securityRequired}} set to {{true}}. * When the caller principal for the EJB2 bean is anonymous, the corresponding {{EJBComponentDescription}} always has {{securityRequired}} set to {{false}}. * Whether or not security is required for the {{EJBComponentDescription}} gets set in [EJBSecurityViewConfigurator|https://github.com/wildfly/wildfly/blob/1bf99...]. * The {{EJBSecurityViewConfigurator}} gets called for each view that is associated with the {{EJBComponentDescription}}. * For EJB2, unlike EJB3, there are actually two views associated with the {{EJBComponentDescription}}: {{server.SomeEJB2}} and {{server.SomeEJBHome}}. Currently, whether or not security is required for the {{EJBComponentDescription}} associated with the EJB2 bean depends on the order in which these two views are processed. If {{server.SomeEJB2}} is processed last, {{securityRequired}} will be set to {{true}} since it has method level security metadata. However, if {{server.SomeEJBHome}} is processed last, {{securityRequired}} will be set to {{false}} since it does not have method level security metadata. The following PR fixes this by ensuring that {{EJBComponentDescription#setSecurityRequired}} only gets called in {{EJBSecurityViewConfigurator}} if security is actually required to avoid resetting the value when there are multiple views: https://github.com/wildfly/wildfly/pull/12468 -- This message was sent by Atlassian Jira (v7.12.1#712002)