JACC: Policy Configuration needs to be linked with children

[anil.saldhana]

Assume that an EAR contains a ejb-jar as well as a war. There is a need to link the policy configuration at the ear level to the PC for the individual constituents of the EAR.

Currently, in the EJBModule.java, the following piece of code is returning null for the parent policy configuration (parentPC):

DeploymentContext current = deploymentUnit.getDeploymentContext();
while (current.getParent() != null)
 current = current.getParent();
PolicyConfiguration parentPC =
current.getTransientAttachments().getAttachment(PolicyConfiguration.class);

if (parentPC != null && parentPC != pc)
 parentPC.linkConfiguration(pc);

This is important for ejb21, ejb3 and web deployments.

[anil.saldhana]

Does the EARDeployer(mean the EARStructureDeployer) need to create this transient attachment for PolicyConfiguration?

[starksm64]

Yes, and we should replace this traversal through the deployment unit contexts with
org.jboss.deployers.plugins.deployers.helpers.AttachmentLocator.search(DeploymentUnit unit, Class type) to limit the number of areas touching deprecated classes.

[anil.saldhana]

Bill has written two deployers in this regard - JaccInitializationDeployer and JaccCommitDeployer in server-org.jboss.deployment.

It makes use of DeploymentContext. It would have been better to have a EARDeployer which basically creates a PolicyConfiguration and puts it as an attachment.

Bill's deployers go through the attachments and link it to their parents. I think this is unnecessary as the ejb and web deployers would do this anyway.

[anil.saldhana]

Scott, I placed a new EARInitializingDeployer that can do jacc policy configuration initialization for the EAR.

[anil.saldhana]

Some information from Scott on this:

***I don't believe the jacc policy linking is being handled correctly currently. In the discussions we had around this in the forums I believed we needed to separate out linking into a separate aspect that had component deployers registering their local policies on whatever the root policy was in the deployment graph. The lifecycle of the aspect is what should be triggering the policy refresh and commit behaviors. This should not be done by deployers.

***but we are overusing deployers. Deployers should not be manipulating the runtime state of components. Deployers should only be manipulating metadata that is consumed by the kernel deployer at which point, the lifecycle of the components triggers the correct transition to running objects based on dependencies and aspects associated with the component.

***
maybe its just that we are not comfortable with the new model. A large part of it is that what the legacy deployers do is wrong under the mc model, and moving to the correct way of doing this is not a trivial port of code. As the profile service is brought into the picture, we will have to be even more clear about deployer operation as an assembly line that takes metadata in and outputs its transformation without doing too much in terms of assumptions regarding runtime behavior of components.

Bill gave this example over IM for lifecycle:

Bill: Create a Bean for the EAR
Bill: create() creates the policy
Bill: start() commits it
Bill: EJB Containers are beans which depend on EAR bean
Bill: create() registers
Bill: registers and commits

[starksm64]

I don't really follow the bean example. There are examples of deployers "creating" service beans by setting up the ServiceMetaData for the bean for the ServiceDeployer to pickup. This is just an expression of the bean in terms of its metadata, and includes things like dependencies:

 protected void deployWebModule(DeploymentUnit unit, WebMetaData metaData,
 AbstractWarDeployment deployment)
 throws Exception
 {
 log.debug("deployWebModule");
 try
 {
 ServiceMetaData webModule = new ServiceMetaData();
 String name = getObjectName(metaData);
 ObjectName objectName = new ObjectName(name);
 webModule.setObjectName(objectName);
 webModule.setCode(WebModule.class.getName());
 // WebModule(DeploymentUnit, AbstractWarDeployer, AbstractWarDeployment)
 ServiceConstructorMetaData constructor = new ServiceConstructorMetaData();
 constructor.setSignature(new String[] { DeploymentUnit.class.getName(),
 AbstractWarDeployer.class.getName(), AbstractWarDeployment.class.getName()});
 constructor.setParameters(new Object[] {unit, this, deployment});
 webModule.setConstructor(constructor);

 // Dependencies...Still have old jmx names here
 Collection<String> depends = metaData.getDependencies();
 List<ServiceDependencyMetaData> dependencies = new ArrayList<ServiceDependencyMetaData>();
 for(String iDependOn : depends)
 {
 ServiceDependencyMetaData sdmd = new ServiceDependencyMetaData();
 sdmd.setIDependOn(iDependOn);
 }
 webModule.setDependencies(dependencies);

 // TODO could create multiple components for the deployment
 unit.addAttachment(ServiceMetaData.class, webModule);
 }
 catch (Exception e)
 {
 throw DeploymentException.rethrowAsDeploymentException("Error creating rar deployment " + unit.getName(), e);
 }

 }

The jacc policy for the deployment could be a kernel bean or service bean. I think what we need is a JaccPolicy instance that manages the lifecycle of all the policy configurations, and a security deployer manages the metadata for this. The first security metadata in a deployment triggers the security deployer to create the JaccPolicy service/kernel bean metadata, and then the jacc policy configuration metadata for components is associated with the JaccPolicy by injection for example.

The component deployers need to have a dependency on the JaccPolicy so that the policy lifecycle is triggered before the components are fully started.

[anil.saldhana]

One JaccPolicy bean per deployment or for all the deployments? I think you meant one per deployment.

http://jira.jboss.com/jira/browse/JBAS-3932


Also, we just have a dtd for jboss-app.xml. We have not created a schema for this. I am wondering if "depends" tag is applicable at the ear level. We can do it at the ejb-jar level via jboss.xml

[starksm64]

One per top level deployment. You don't need a schema for the dependency as it not going to be expressed in any descriptor. Its a runtime dependency that the security deployer adds to the component that expresses the fact that the reference to the security metadata has introduced a dependency on the policy object. If a different (non-jacc) security deployer is in use because jacc is not being used, then there would be no JaccPolicy.

[anil.saldhana]

I was wondering if a "depends" tag is applicable in jboss-app.xml

[starksm64]

No, because the dependency on a particular implementation of the security aspect is not deployment level metadata. The deployment specifies the security domain and j2ee permissions/roles. Its a server configuration that says the security aspect is using jacc and the associated deployer introduces the metadata for the components that implement jacc.

That is not to say in the future we might have directives that control the deployment processing, but we should not be overloading the legacy descriptors with new aspects. The security configuration aspect should be another layer independent of jboss-app.xml, jboss.xml, etc.

[anil.saldhana]

I am asking a generic question (not related to security deployer for jacc).

jboss.xml supports "depends" tag - has a schema file.
jboss-web.xml does not support "depends" tag. Just has a dtd file.
jboss-app.xml does not support "depends" tag. Has a dtd file.

You really have been on a roll yesterday, Scott.

[anil.saldhana]

To completely not use the concept of "DeploymentContext" from a DeploymentUnit, how does one deal with getting the parent deploymentunit, for example.

[starksm64]

To completely not use the concept of "DeploymentContext" from a DeploymentUnit, how does one deal with getting the parent deploymentunit, for example.

We need to expose parent/child relationship on the DeploymentUnit.

[starksm64]

I am asking a generic question (not related to security deployer for jacc).

jboss.xml supports "depends" tag - has a schema file.
jboss-web.xml does not support "depends" tag. Just has a dtd file.
jboss-app.xml does not support "depends" tag. Has a dtd file.

jboss-web.xml does support a depends element.

jboss-app.xml does not support depends because its not a component deployment. Its more of a packing notion. Anything needing a dependency in an ear would have its own depends support in its descriptor.

In terms of dtd vs schema, everything should be moved to schemas.

In general the need for depends is a hack around not having proper dependency associated by the component deployer. If I reference a jndi resource, a dependency on the provider of that binding should be created by the container that resolves the reference. ejb3 has started doing this for injections.