I started looking at the sources. More specifically I looked into com.sun.enterprise.security.provider.PolicyConfigurationImpl where IMHO the first exception (maybe the root cause of my trouble) occurs in method generatePermissions() saying this:
SEVERE: Linked policy contexts have different roleToSubjectMaps [com.hmg.test.ear.1/com_hmg_test_web_war] [com.hmg.test.ear.1/com_hmg_test_web_war_internal]
This happens only once for every virgin deployment. If I redeploy my EAR with the same name, my breakpoint in PolicyConfigurationImpl is not hit at all.
After PolicyConfigurationImpl.generatePermissions() failed once, the following exception is logged multiple times afterwards:
SEVERE: Exception while loading the app
org.glassfish.deployment.common.DeploymentException: Error in linking security policy for com.hmg.test -- Inconsistent Module State
at com.sun.enterprise.security.SecurityUtil.linkPolicyFile(SecurityUtil.java:329)
at com.sun.enterprise.security.SecurityDeployer.linkPolicies(SecurityDeployer.java:275)
...
I can only trigger the code in PolicyConfigurationImpl.generatePermissions() again by renaming the EAR or alternatively by deleting the EAR-related files in the following directories:
${glassfish3}/glassfish/domains/domain1/autodeploy/.autodeploystatus/
${glassfish3}/glassfish/domains/domain1/generated/policy/
For every "virgin" deployment, GF enters the method generatePermissions() twice. Once of the CONTEXT_ID = "com.hmg.test/com_hmg_test_web_war_internal" and once for the CONTEXT_ID = "com.hmg.test/com_hmg_test_web_war".
The first time, roleToSubjectMap and rolePermissionsTable are both null. The second time rolePermissionsTable exists (and contains quite a few entries). This causes the SecurityRoleMapperFactory to be asked for a SecurityRoleMapper which then sets roleToSubjectMap to a Map containing these entries:
{_Guest_=Subject:
Principal: _Guest_
, com.hmg.test.role001=Subject:
Principal: com.hmg.test.role001
}
This looks so far OK, but then it compares the assigned roleToSubjectMap to these two contexts:
com.hmg.test/com_hmg_test_web_war, com.hmg.test/com_hmg_test_web_war_internal
The first is skipped (because it's the same) and for the second, a different SecurityRoleMapper is obtained which returns a different (empty!) otherRoleToSubjectMap leading to the exception.
Could someone please answer the following questions:
1) Am I experiencing a GF bug or is something wrong with my EAR? If so, what's wrong?
2) Why are there two contexts (one suffixed "_internal" for my WAR)? Shouldn't there only be one?
3) Why are the roleToSubjectMaps compared using "!="? The code tests for identity, even though the two contexts have different SecurityRoleMapper instances assigned. Is there any chance at all that they are not only equal but really the same instances?
4) Why does the internal context has no role-to-subject-map while the non-internal looks OK?
Best regards, Marco :-)
[Message sent by forum member 'nlmarco']
http://forums.java.net/jive/thread.jspa?messageID=484377