Thanks for putting out your explorations...(see below)
On 05/10/10 8:05 PM, glassfish_at_javadesktop.org wrote:
> 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?
I discussed with Deployment and EJB experts and it is a Bug in GF.
> 2) Why are there two contexts (one suffixed "_internal" for my WAR)? Shouldn't there only be one?
The packaging that you have is valid according to EJB experts however it
is a bit unnatural (EJB in a WAR scenario). Here is what he has said :
----------
The lib/*.jar is made available to all component archives, including
this war file (com.hmg.test.web.war), and a war file can include EJB
classes by direct inclusion or by direct inclusion or by reference.
Using EAR lib mechanism is one way of reference.
But since we are already using EAR packaging in this case, it's a bit
unnatural to use EJB-in-WAR packaging.
-----------
Do you really need this kind of packaging where you only declare the web
module in application.xml and not the EJB.
regards,
kumar
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>