Aspectized JACC deployment layer

[bill.burke]

I partitioned out the JACC layer into the server module under

org.jboss.deployment.JaccInitializationDeployer
org.jboss.deployment.JaccCommitDeployer

It feels almost a little hacky, why? The JaccInitializationDeployer takes a set a set of attachment names. If the deploymentContext contains that transient attachment, then it will add PolicyConfiguration. The idea being that you can trigger JACC based on whether or not a given DU is a certain type of deployment (is it an EAR WAR or EJB JAR?)

[starksm64]

I would be more inclined to create an encompassing SecurityMetaData instance that had a jacc flag, or even use a jacc-context setting to trigger whether or not the jacc policy was created as part of a AbstractSimpleRealDeployer that dealt with all of the security stuff.

[adrian.brock]

Why would a real deployer create anything like this?

Surely it should be creating the metadata for an MBean or POJO
that can take part in dependencies?

[adrian.brock]

It feels almost a little hacky, why? The JaccInitializationDeployer takes a set a set of attachment names. If the deploymentContext contains that transient attachment, then it will add PolicyConfiguration. The idea being that you can trigger JACC based on whether or not a given DU is a certain type of deployment (is it an EAR WAR or EJB JAR?)

Why is that hacky? That is whole point of aspectized deployers.
You can create the deployment aspect for all deployment types
(based on whether the metadata exists).

Whether it actually makes sense in all cases is a different issue, :-)
See my critique of "orthogonality" in the overview post at the top
of the forum.

[starksm64]

Why would a real deployer create anything like this?

Surely it should be creating the metadata for an MBean or POJO
that can take part in dependencies?

That is what I said we should be doing when the discussion of the JaccCommitDeployer trying to manage the policy config lifecycle commit.

[bill.burke]

The problem is that an EAR does not know what dependencies are on its PolicyConfiguration, so it cannot register anything with the MC until all its EJBContainers have been registered and their policies linked.

[starksm64]

We have to be able to build up dependencies across deployers. If the metadata for the mbean/pojo security layer cannot be done this way, then you need a security metadata deployer that runs after deployment type deployers to merge the security metadata to build the proper instances.

The naturual place for this is every container needs a dependency on a SecurityDomain object to gain access to the authentication/authorization interfaces. We need to talk through how this can happen such that the jacc policy configuration object lifecycles tie into the top level deployment starting.

[starksm64]

And relating this to our call this morning, each component deployer that utilizes jacc can create the kernel bean metadata for the policy configuration instances, and tie that into the kernel bean metadata for the policy configuration container object. Each container would have to declare a dependency on the policy configuration container object. When the kernel bean deployer instantiates the policy configuration container, all deployers will have associated their policy configuration object dependencies.

[wmprice]

Was there a dev call? Was this open to anyone? Is this something you guys schedule on a regular basis?

[starksm64]

"wmprice" wrote:
Was there a dev call? Was this open to anyone? Is this something you guys schedule on a regular basis?

Its a post call on the javaee5 tck status since the reworking of the deployers is changing how the ee container deployments are done. Anyone can join.