Deployers and service dependencies

[heiko.braun]

A custom deployer (stage=REAL) depends on the TransactionManager. I tried the MC 'depends' clause, however when the undeployment kicks in the dependency is not satisfied anymore.

What would be the proper way to set it up? AFAIK the deployer ordering is done through the input and output set definitions. So it's probably independed of the IOC dependencies, but is there a way to achieve what I described above?
Or is the whole approach wrong to begin with?

[alesj]

A custom deployer (stage=REAL) depends on the TransactionManager. I tried the MC 'depends' clause, however when the undeployment kicks in the dependency is not satisfied anymore.

Who's undeployment and which dependency?
If TM is undeployed, your deployer is un-winded as well.

What would be the proper way to set it up? AFAIK the deployer ordering is done through the input and output set definitions. So it's probably independed of the IOC dependencies, but is there a way to achieve what I described above?

Achieve what?

You might run into this:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151549

[heiko.braun]

The deployer requires the transaction manager for successful deployment/undeployment (It involves JDBC datasources).
Deployment works fine, because the deployer kicks in after TX manager has been initialized. However upon undeployment the dependency is removed first and then deployer is invoked.

[heiko.braun]

the dependency is removed first and then deployer is invoked

I would expect it the other way around, if a depends clause is specified.
But maybe i got it wrong.

[heiko.braun]

jboss-dependency.xml:

You can define generic dependencies of your deployment wrt other deployments or even services.
e.g. my x-app.ear should start after x-util.jar is installed
e.g. my z-app.war depends on TransactionManager bean

Is there additional docs besides the WIKI page?

[alesj]

I see what you mean and I know what the problem is. :-)

This is what happens:
* TM is ready to be undeployed
* list (X) of all deployers for Real is prepared
* BeanMDDeployer for TM kicks in --> unwinding your JDBC deployer
* your JDBC deployer is still used since it was part of X list

Either move your JDBC deployer to diff deployment stage,
or somehow move it before BMDDeployer on undeployment.

[heiko.braun]

It's actually two deployers: a metadata deployer (stage=PARSE) and the one with the TM dependency (stage=REAL) that specifies an input requirement on the metadata. But that's just for the records.

Is the BMDDeployer the one that picks up *-beans.xml?

[heiko.braun]

or somehow move it before BMDDeployer on undeployment.

How would i do that? I got the impression that deployers are only ordered by input/output set definitions, no?

[alesj]

Is the BMDDeployer the one that picks up *-beans.xml?

No, it's BeanDeployer.

The rest are:
* KernelDeploymentDeployer --> split BMD into components
* BMDDeployer --> install BMD into MC's Controller

[alesj]

or somehow move it before BMDDeployer on undeployment.

How would i do that? I got the impression that deployers are only ordered by input/output set definitions, no?

Yes, only inputs/outputs.
OK, in the worst case relative order.

But more importantly, why do you need it in Real?

[heiko.braun]

But more importantly, why do you need it in Real?

Not necessarily, at most i'd need CLASSLOADER. I just took an appropriate base class. What would it change if I move it ? (Read: When do you write the docs ;)

[alesj]

What would it change if I move it ?

How can I know if I have no clue what you're doing. ;-)

[heiko.braun]

I am trying exactly what you described in the wiki. Have a deployment depend on a service as described here: http://www.jboss.org/community/docs/DOC-13178

[heiko.braun]

I am currently looking into DependenciesMetaData. Maybe you can confirm that my understanding is correct.

1) jboss-dependency.xml works with a single deployment unit.
2) Hence I introduced a deployer that prepares the dependencies for particular deployments similar to what the Ejb3DependencyDeployer does:

 public JBPMDependenciesDeployer()
 {
 setStage(DeploymentStages.PRE_REAL);
 setOutput(DependenciesMetaData.class);

 DeploymentVisitor<JBPMDeploymentMetaData> visitor = new DeploymentVisitor<JBPMDeploymentMetaData>()
 {
 public void deploy(DeploymentUnit unit, JBPMDeploymentMetaData deployment)
 throws DeploymentException
 {
 log.info("Encountered deployment " + unit);

 unit.addIDependOn(
 new AbstractDependencyItem(unit.getName(),
 TransactionManager.class,
 new ControllerState("Real"),
 ControllerState.INSTALLED)
 );
 }
[...]
}

I would expect any JBPMDeploymentMetaData that passes the visitor to have a dependency on the TransactionManager. Right?
Which means to me, that upon undeployment these deployment units are processed before the TM leaves INSTALLED and hence would still be still be available.

Is that how it should work? Maybe the error is somewhere else.

[alesj]

I am currently looking into DependenciesMetaData.

You don't need DependenciesMetaData unless you're really creating it
and as such delegating the work to true DependenciesMetaDataDeployer.

e.g. you could just provide the right DependenciesMetaData into attachments
which would then be picked up by the deployer that already handles it.
Hence no need for your deployer to explicitly add dependency items

1) jboss-dependency.xml works with a single deployment unit.

Not really.
You can have multiple jboss-dependency.xmls in multiple (sub)deployments.
But at the end, they all get added to top deployment,
as that's the only one we track in MC's state machine.

2) Hence I introduced a deployer that prepares the dependencies for particular deployments similar to what the Ejb3DependencyDeployer does:

 public JBPMDependenciesDeployer()
 {
 setStage(DeploymentStages.PRE_REAL);
 setOutput(DependenciesMetaData.class);

 DeploymentVisitor<JBPMDeploymentMetaData> visitor = new DeploymentVisitor<JBPMDeploymentMetaData>()
 {
 public void deploy(DeploymentUnit unit, JBPMDeploymentMetaData deployment)
 throws DeploymentException
 {
 log.info("Encountered deployment " + unit);

 unit.addIDependOn(
 new AbstractDependencyItem(unit.getName(),
 TransactionManager.class,
 new ControllerState("Real"),
 ControllerState.INSTALLED)
 );
 }
[...]
}

I would expect any JBPMDeploymentMetaData that passes the visitor to have a dependency on the TransactionManager. Right?
Which means to me, that upon undeployment these deployment units are processed before the TM leaves INSTALLED and hence would still be still be available.

Is that how it should work? Maybe the error is somewhere else.

This looks OK.
What's the error?

But as suggested, I would do it differently.
I would just create a proper version of DependenciesMetaData,
leaving its deployment to DependenciesMetaDataDeployer and DeploymentDependencyDeployer.
Just make sure they are in the right deployment stage.