[jboss-dev-forums] [Design of POJO Server] - DataSource/ServiceXSLDeployer processing issue

[scott.stark@jboss.org]

A problem I ran into while trying to implement the CRUD usecases for *-ds.xml deployments is that the metadata representation of a datasource deployment should be a ServiceDeployment with a xml dom representation of the *-ds.xml deployment. It currently is a ServiceDeployment with a xml dom representation of the transformed *-service.xml containing the jca mbeans.

The two problems that exist are:
1. the profile service only wants to rerun the deployment processing from the Deployer.CLASSLOADER_DEPLOYER on to avoid duplicate metadata parsing and overwriting of the overriden attachment metadata coming from the ManagedObject updates. However, for a datasource deployment, the xsl transform occurrs during the parsing phase. The datasource deployment therefore would need to be run through the parsing deployers. 
2. the datasource deployment does not have a valid representation of the *-ds.xml metadata. There is no xml dom view of the original *-ds.xml that can be updated via ManagedObject/ManagedProperty bindings. The xsl transform always goes to the *-ds.xml VirtualFile and applies the transform to the dom that results from parsing it.

The general issues are deployers not having overridable metadata representations, and not knowing where to start the parsing. The latter issue is really more of not being able to simply rerun all deployers and only have those which have work to do function. I view this is an issue with not having the DeploymentUnit attachments api sufficiently well defined. As a review, here is the current state of the attachments api and its meaning.

Deployers deal with DeploymentUnits as the view on a deployable unit of work. There are two types of DeploymentUnits, containers which can top-level deployments (ears, ejb-jars, wars, sars, -beans.xml, ...), and components which belong to a container deployment (ejbs, mbeans, mc beans, servlets, ...). Components are associated with their container via DeploymentUnit.addComponent(String). Container type deployment can be nested structurally as well, but the DeploymentUnit does not currently expose an api for accessing this. Its a todo.

Metadata can be associated with a DeploymentUnit. This is done using the Attachments api. There are a few different levels of Attachments. A DeploymentUnit is an extension of the Attachments api. A DeploymentUnit also has an Attachments accessed via getTransientManagedObjects(). Adding an attachment via addAttachment adds a transient attachment. To add a transient managed object attachment, call getTransientManagedObjects().addAttachment.

The difference between a transient attachment and transient managed object attachment is that transient managed object attachments are overrides to transient attachments. When you call the DeploymentUnit.getAttachment(), the implementation first looks for a transient managed object attachment override. If that is not found, then the transient attachments are consulted. Deployers should only populate the transient attachments while admin interfaces like the profile service populate the transient managed object attachments.

One should be able to run a deployment trough the deployers, and then re-run the resulting DeploymentUnit through again and have this essentially be a noop in terms of the creation of metadata attachments as a Deployer should look for an existing attachment and avoid recreating it from the deployment content. One area which this is broken is when more than one parsing deployer populates the same metadata model from multiple sources. This happens for standard descriptors/annotations that can be augmented/overriden by jboss descriptors/annotations. With the addition of the DeploymentUnit Set getTypes(), the check for whether parsing should be done in the case of shared metadata attachments could be whether the attachments exist, and the DeploymentUnit has been marked as being of the curent Deployer.getType().

For the datasource deployment issue, the XSL deployers still need to support a dom attachment that represents the pre-transformed xml model so that it can be overriden.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005030#4005030

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005030