[anil.saldhana]

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.

A method

DeploymentUnit getParent();

is needed on the DeploymentUnit.

[anil.saldhana]

Deployment Unit:

Object addAttachment(String name, Object attachment);
<T> T addAttachment(String name, T attachment, Class<T> expectedType);
<T> T addAttachment(Class<T> type, T attachment);

Minor issue: the addition of attachments with reference to Class and the attachment itself is not consistent across the api (mainly the second and third add attachments)

* I am assuming that a deployment can have multiple service beans.

* Now if a deployer wants to remove an attachment in its undeploy method, it is better to have added the attachment with a name??

unit.addAttachment("somename",bean, ServiceMetaData.class);
unit.removeAttachment("somename", ServiceMetaData.class);

[starksm64]

Add type a class assumes a single instance of that type. This is simply a convience method for addAttachment(expectedType.getName(), T attachment, Class expectedType). If there are multiple instance of a type you would need different names.

The ServiceMetaData example does not apply. Each ServiceMetaData instance is associated with a component deployment, a type of DeploymentUnit that has no children. DeploymentUnit component is structurally related to the owning deployment unit (a ServiceDeployment for a ServiceMetaData), and each service is a child component deployment unit with a single ServiceMetaData.

I'll look to add the getParent today.

[anil.saldhana]

The ServiceMetaData example does not apply. Each ServiceMetaData instance is associated with a component deployment, a type of DeploymentUnit that has no children. DeploymentUnit component is structurally related to the owning deployment unit (a ServiceDeployment for a ServiceMetaData), and each service is a child component deployment unit with a single ServiceMetaData.

Explain this in the context of the Security Deployer.

Eg:I have a top level deployment, an ear file. Now how does one create the JaccPolicy service bean (the Security Deployer can create the service metadata). But how does it add it to the deployment unit? What really needs to happen here.

[starksm64]

I would look to implement the security deployer as one that:

- Created a child component for the JaccPolicy on the top-level deployment
- for each deployment context with security metdata that affects the JaccPolicy(and the top-level deployment may apply as in the case of standalone ejb jars, wars), either augment the JaccPolicy metadata, or create another pojo for the jacc permissions that need to link to the JaccPolicy.

The first step is to define the pojos and metadata needed to introduce a jacc security policy into a standalone mc deployment, and then come back to how to integrate these into the jbossas deployments.

[anil.saldhana]

Ignore my last post, Scott. I think I got it.

[anil.saldhana]

Is it possible to get a method in some DeploymentUnitUtil with the following signature:

public String getShortName(DeploymentUnit)

This is needed for the jacc context id that is void of any url sematics as well as the suffix (jar,sar,war etc).

[starksm64]

Why doesn't DeploymentUnit.getSimpleName() work?

[anil.saldhana]

Why doesn't DeploymentUnit.getSimpleName() work?

/**
 * Get the simple vfs name of the deployment unit. This is the simple
 * name of the virtual file .
 *
 * vfs path ------------------- simple name
 * deploy/some.ear "some.ear"
 * deploy/some.ear/x.ejb "x.ejb"
 * deploy/some.ear/y.sar "y.sar"
 * deploy/some.ear/y.sar/z.rar "z.rar"
 * deploy/complexwithappxml.ear/module-mbean1.sar/submbean.sar submbean.sar
 * @return the deployment unit simple path
 */
 public String getSimpleName();

I thought we wanted to remove the suffix(jar,war) from the context id.

[starksm64]

I don't think so. Its better that the default be tied to the deployment structure in some way.

[anil.saldhana]

An issue I am seeing is that the policy configuration for the top level deployment cannot go into "inService" until the linking for the sub-deployment policy configuration(s) has been performed.

Here is the usecase:
- Create a service bean JaccPolicy for the top-level deployment
- Create Parent PC
- In the start method of the service bean, you can do pc.commit()
- Now that the dependent JaccPolicy has started up, the subdeployment injects its metadata/pc into the jaccpolicy, which needs to link the pc with the parentPC. It cannot because the top-level pc has already gone into "inService" state.

The issue is the top level deployment unit needs to have a hook into all the subdeployments (including archives sitting inside zipped up archives) such that the top level parentPC can decide to commit once it knows that all the subdeployments have linked to it.

Any feedback on the approach?

[starksm64]

The dependencies/relationships between the components needs to be setup such that inService is not reached until the deployment policy configs are known. You have to realize that you are setting up metadata/relationships before any objects are created. All deployments are processed for each deployer so once your past a given phase of deployment, all required info exists for the next phase.

[starksm64]

I suggest you create a testcase that excercies the type of cross deployment unit relationships we are talking about here in the jbossmc project so that its clear what the mc/vdf supports, and we have validation of the expected behavior independent of the details of the jboss5 deployers.

[anil.saldhana]

I have this coded and my final testing with the tck is looking good. I will have this checked in, in few hours. You can review the code then and then give me some feedback.

Basically, have a
a) central place (JaccPolicy service bean) to create the jacc permissions given the metadata, link the policy configuration to the top-level pc etc.
b) security deployer to take care of the service metadata for the Jacc Policy for top-level deployments.
c) The component deployers have dependence on the JaccPolicy.

Over further iterations, I can get this straight.

[anil.saldhana]

Scott, the first phase of checkin for Security deployer has happened. You can take a look and provide feedback.

There are multiple places where improvement/correction may be needed.