Actually, JBoss requires that <security-role> or <role-name> are exactly the groups you can find in your security realm. As a result, if you want your application to be available to the role "myApplicationRole", you have to setup a group in your realm with the name "myApplicationRole".
Now if you want to restraint a specific feature to role1, using request.isUserInRole("role1"), you have to setup a <security-role-link> to map role1 to a group of your realm. This works well if this feature maps to a single role. If this feature maps to let's say 2 different groups (gr1 and gr2) of your realm, you have to create a new group in your realm, let's say "myFeatureGroup", put gr1 and gr2 in myFeatureGroup in order to see it works. You now have a application specific group in your global realm. I think we should avoid this.

I suggest to add the ability to map a role to 1-m group using jboss-web.xml (I thought it was aimed at it) so we could have :

web.xml :
<security-role>myRole</security-role>

and in jboss-web.xml
<security-role>
<role-name>myRole</role-name>
<principal-name>j2eegourp</principal-name>
<principal-name>joe</principal-name>
</security-role>

and joe is a user and j2eegroup are security groups.
Using this, we have the following advantages :

• application only deals with roles, and not security groups
• security groups only deals with global groups and not applications specific roles
• there is a clear separation between roles and groups.