JACC Policy Bean not getting injected into EJBModule

[anil.saldhana]

When I have a ejb jar, the security deployer creates a JaccPolicy Bean for the top level deployment and adds it to the deployment as follows:

//Create a Service Bean for the JACC Policy
 ServiceMetaData jaccPolicy = new ServiceMetaData();
 jaccPolicy.setCode(JaccPolicy.class.getName());
 try
 {
 jaccPolicy.setObjectName(new ObjectName(JaccPolicy.BASE_OBJECT_NAME + contextId));
 }
 catch (Exception e)
 {
 }

//Now add this service bean to the unit
 ServiceDeployment sd = new ServiceDeployment();
 sd.setServices(services);
 unit.addAttachment("jboss.jaccpolicy", sd, ServiceDeployment.class);

I then expect an injection of JaccPolicyMBean into EJBModule. This is not happening. Scott, I think your last cycle of changes may have had an effect on this?

Simplest way to test this:
Create a jacc server configuration by running the target "ant tests-jacc-security" and then run the following.

ant -Dtest=org.jboss.test.jacc.test.CallerInRoleUnitTestCase one-test

This is the primary reason for the jacc failures in the test suite.

I think the call "unit.addAttachment" needs to be looked at.

The same phenomenon is probably applicable to web deployments also.

[anil.saldhana]

While we are on this topic, could you tell me what the replacement for these calls are, to avoid usage of deployment context:

deploymentunit.getDeploymentContext().isTopLevel();

and

Set<DeploymentContext> children = unit.getDeploymentContext().getChildren();
//I just need the simple names of the children

Update from Anil:
- Scratch the first question. I think unit.getParent() == null signifies top level.

[anil.saldhana]

Scott, did you get a chance at looking why JaccPolicyMBean is not getting injected due to transient dependence on the containers (ejb/web)?

[anil.saldhana]

Transient dependence, sorry.

[starksm64]

Where is the ServiceDependencyValueMetaData on the JaccPolicy being created? I don't see it.

[anil.saldhana]

EJBDeployer and AbstractWarDeployer.

Now that you have mentioned it, I think I will have to recheck my logic.

[starksm64]

I see ServiceDependencyValueMetaData for tm, webservices, ccm, etc, but nothing for the jacc layer currently.

[anil.saldhana]

under ejb/deployers

http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/ejb/deployers/EjbDeployer.java

//Add a dependence on the jacc policy only if we are not the top-level deployment
 if(!JaccPolicyUtil.isTopLevelDeployment(unit))
 {
 attrs.add(JaccPolicyUtil.getServiceAttributeMetaData(unit));
 }

[anil.saldhana]

For a top level deployment, the Security Deployer creates a JaccPolicy bean. The JaccPolicy bean also keeps track of all the subdeployments that are jacc capable (ejbs,wars). As and when each of the jacc capable sub-deployments link their PC, they are removed from the internal list. If all the sub-deployments have linked their pc, then the parentpc commits.

The sub-deployments (ejbs,web) need an injection of JaccPolicy to link their PC with it.

[starksm64]

Ok, I don't know then unless its another symptom of the http://jira.jboss.com/jira/browse/JBMICROCONT-159 issue.

[anil.saldhana]

It probably is. Also, we need to adapt the deploy method of AbstractWebDeployer to use the updated API for DeploymentUnit ie. unit.getParent() and unit.getSimpleName().

This will remove the usage of DeploymentContext.

[anil.saldhana]

Is there an equivalent of:

Set<DeploymentContext> children = unit.getDeploymentContext().getChildren();

Something like:

Set<DeploymentUnit> children = unit.getChildren();

[starksm64]

There isn't one. What is the need you have?

[starksm64]

The check on the top-level deployment was never valid. I changed it to check for a null parent and I see the policy being injected.

[anil.saldhana]

Scott, thanks for the SecurityDeployer cleanup that you made.

Set<DeploymentUnit> children = unit.getChildren();

is needed by deployers dealing with top level deployments to know what embedded deployments exist?

An example would be the JaccPolicy bean that works at the top level and it cannot commit the PolicyConfiguration until everyone underneath has linked to it.