Deployer sequencing

[gcompienne]

Hello, I am trying to understand JBoss MC and there is a thing on deployer sequencing that I don't understand:

When JBoss MC is used in the context of JBoss AS I can see that the HackClassloaderMetaDataDeployer class is only being triggered by the deployment of "console-mgr.sar". Now I must admit I don't understand why is that happening as the HackClassloaderMetaDataDeployer does not seem to be setting any input ("setInputs") or output ("setOutput").

When I tried to write my own deployer I was able to ensure that it was always called ("setAllInputs(true); ") but I really don't understand why HackClassloaderMetaDataDeployer behaves as it currently do...

Thanks for your help.

Gilles.

[alesj]

Behaving as what?
Being only triggered once (which I doubt is the case) or why there are no inputs/outputs?

[gcompienne]

As far as I can see it is only triggered once (looking at the log file) for a default jboss run (includes an EJB 3 bean and a few other test deployers).

In fact I am trying to understand the exact relationships and rules existing between the classloader that seem to be created by the structure deployers and the "DESCRIBE" and "CLASSLOADER" deployers.

I discovered HackClassloaderMetaDataDeployer and though "That's probably a good one to start with" but then I was troubled when I realized it was only called when "console-mgr.sar" is being deployed...

I initially though that the fact it does not set input/outputs would have meant it matches all deployments (or perhaps none)... But that does not seem to be the case...

[alesj]

What AS5 instance are you running?

Did you check the HackCLMDD code?
There are (currently) two usages.
1) there is LoaderRepositoryConfig present in attachments
2) we're not top level deployment unit, and there is parent CLMD present

This deployer is always triggered.
And all it does - applying the 2 rules from above - is add ClassLoaderMetaData.
This CLMD is later picked by ClassLoaderDeployer (if it exists).

Regarding 'console-mgr.sar', I guess this is the only deployment that has strict scoping defined, hence the LoaderRepositoryConfig being present.

 <loader-repository>
 jboss.console:sar=console-mgr.sar
 <loader-repository-config>
 java2ParentDelegation=true
 </loader-repository-config>
 </loader-repository>

[gcompienne]

Arghh... My bad. I completly forgot to notice that the "log.debug" command was after the "if" that was checking the presence of the LoaderRepositoryConfig...

Sorry...

But thanks for your useful help.

Gilles.

[alesj]

Source code is your friend. ;-)

[gcompienne]

But this seems to confirm that if I don't specify any input then the deployer is always called (rather than never).

So far I was always doing a "setAllInputs(true)" but that probably was not necessary...

Thanks again.

Gilles.

[alesj]

"gcompienne" wrote:
But this seems to confirm that if I don't specify any input then the deployer is always called (rather than never).

So far I was always doing a "setAllInputs(true)" but that probably was not necessary...

Inputs/outputs have only one struct usage, and that's the 'natural' order.
If you do your deployers correctly, they can be naturally ordered by their inputs/outputs, like dominos.

The second use case - if they are present in attachments - is optional. It depends on what you want to do with that info.
e.g Most of deployers generically check if that type of attachment is present, else just pass through.

But you can do what ever you like. ;-)