Active Deployer Development?

[darranl]

Is there any active development in the area of the JBoss deployers at the moment?

The reason that I am asking is because I have been looking at the following issue: -

http://jira.jboss.com/jira/browse/JBAS-1517

The solution requires a period to be added to all of the suffixes defined in the class SuffixOrderHelper. There are two additional deployers that add their suffixes to the list, these need amending to include a period in the suffix added to the list in SuffixOrderHelper.

The DeploymentSorter class should also have the list of defaults removed as these are no longer really used, at runtime they are replaced by the suffices in SuffixOrderHelper.

For completeness it looks as if all deployers should specify the suffixes of the files that they can deploy. e.g. It should be the ear deployer that specifies that ears can be deployed. Making each deployer return the suffixes of the items that it can deploy seems to be a fairly small task, there are only 11 deployers in the default configuration and 2 of these already do specify their suffixes.

With the current architecture this then leads to another issue, what happens to ordering if multiple deployers can deploy items with the same suffix?

Ideally I would imagine that the suffix would be used to determine what is deployable but then the associated deployer would be determined to work out the order of deployment. e.g. EJBs and Clients are both packaged in jars but it makes sense that the EJBs are deployed first.

From Wednesday this week I have a some days free that I could use to look at this but I would first like to check if this conflicts with any current development and if people think that this approach would be appropriate.

[starksm64]

Currently we do not support multiple deployers for the same content so there cannot be 2 or more deployers that recognize the same deployment types. Work is underway to support a chain of deployers in the next gen server.

The DeploymentSorter defaults should still be used if the MainDeployer is not deployed using an xmbean descriptor, so there is no reason to remove the static defaults.

Every deployer can express their deployment suffixes and relative order using the org.jboss.deployment.SubDeployerSupport Suffixes and RelativeOrder attributes. I think that proper configuration of all deployers to use this should resolve the JBAS-1517 issue. If not, point out what is lacking.

[dimitris]

After the introduction of SuffixOrderHelper setting the DeploymentSorter suffixes is done through the MainDeployer.EnhancedSuffixOrder attribute. If nothing is set, then the default of SuffixOrderHelper apply.

So (a) I would suspect that the change made for JBAS-1264 in DeploymentSorter for the "-ds.xml" probably doesn't solve the problem, and (b) I'd suggest we modify the SuffixOrderHelper defaults to include the dots (.) and the hyphens (-) to solve problems like JBAS-1517.

I'm curious also when the relaxing of the acceptance of the deployable content happend, since I just re-used the existing suffixes for the SuffixOrderHelper (or was it always like this ?)

[darranl]

Dimitris, I have tried adding the '.' to each of the suffixes in the SuffixOrderHelper and that does correct the issues identified in 'JBAS-1517'

I did originally try adding the '.' to the suffixes in the DeploymentSorter but these were overiden by the suffixes in the SuffixOrderHelper.

The two deployers that are registered later will also need their suffixes ammending, I think they were the BeanShell deployer and the Hibernate deployer.

Regarding the multiple deployers for the same deployment type, yes each deployment type can only be deployed by one deployer - however the file extension is not the only mechanism used to identify the deployment type.

The JARDepoyer, EJBDeployer and ClientDeployer all deploy files with the suffix 'jar', their accepts method then checks the contents of the archive to see if it is for that deployer.

The first issue here is that the relative order is something specified by the deployer itself, however the ordering is based on the suffix so if multiple deployers can deploy archives with the same suffix their deployments must all have the same relative order. Here you might like to be able to say that all EJB archives should be deployed before all Client archives.

If each deployer is updated to specify it's own suffix's and relative order there is also an issue regarding registering and unregistering the deployers as the list of suffixes is automatically updated. You wouldn't want the undepoyment of a deployer that supports the 'jar' suffix to remove the 'jar' suffix from the list as other deployers can still deploy it.

[starksm64]

If each deployer is updated to specify it's own suffix's and relative order there is also an issue regarding registering and unregistering the deployers as the list of suffixes is automatically updated. You wouldn't want the undepoyment of a deployer that supports the 'jar' suffix to remove the 'jar' suffix from the list as other deployers can still deploy it.

This is not the case in the 4.0 architecture. The suffixes should form a disjoint set across the deployers.

[darranl]

Scott,

Inside the MainDeployer there is a method 'removeDeployer', inside this method there is the following line: -

suffixOrderHelper.removeSuffixes(deployer.getSuffixes(), deployer.getRelativeOrder());

This removes the suffix from the list in the SuffixOrderHelper.

The 'addSuffixes' method of the SuffixOrderHelper makes sure that each suffix can only be added once.

This would mean that the three deployers 'JARDepoyer, EJBDeployer and ClientDeployer' would result in the 'jar' suffix being added once and the first one to be undeployed would result in the 'jar' suffix from being removed.

This does assume that you are adding the suffixes with the same relative order, however if they are being deployed with different relative orders you are back to the problem that the deployments are not sorted by deployer even if the deployers have different relative orders.

[dimitris]

The question was really whether to allow an extension to appear many times in the suffix list with the same or different relative order. In practice, for the deployment scanner who uses this list, this is unusuable, because it will just utilise the first instance,

e.g if you have .sar, .rar, .jar, .war, .jar, .last, the second .jar is never used while sorting...

So, given the requirement that we needed "a couple" of deployes to register/unregister dynamically (e.g. .aop, .har), and the rest of jboss keep working like before, it was ok to make this assumption.

It's very easy to change this anyway, if we want all deployers to register dynamically.

The immediate question is whether to add the missing '.' & '-'

:-)

[darranl]

Ok, if the requirement is just for the new deployers to be dynamically added this makes sense.

As well as adding the '.'s and '-'s to the suffixes i think the list in the DeploymentSorter should also be removed to avoid confusion.

Thank you both for your feedback.

Let me know if there is anything you would like me to look at regarding this, I do have a couple of ideas if the registration should be made fully dynamic but it really comes down to if you think this is worthwhile in version 4.0. In the meantime I will go back to Jira to see if I can find another issue to look at, any suggestions?

[starksm64]

If you have a security bent then these would be good:

Generalize the LdapLoginModule user and roles search mechanism:
http://jira.jboss.com/jira/browse/JBAS-1525

Add support for customization of the login module password hash mechanism:
http://jira.jboss.com/jira/browse/JBAS-1473


Others:

stop unzipping everything in the deploy on every startup :
http://jira.jboss.com/jira/browse/JBAS-1572

This 'UserTransaction with non default ProviderURL' issue could possibly be addressed in a manner similar to ejb handles:
http://jira.jboss.com/jira/browse/JBAS-1270

[darranl]

Scott,

I will have a look at the LDAP enhancement for security (JBAS-1525).

I need to get familiar with using LDAP with JBoss so I will get myself set up with something working first and get back to you.

[dimitris]

FYI, http://jira.jboss.com/jira/browse/JBAS-1517 has been fixed.

There is still the case where 2 subdeployers registering dynamically the same extension have a problem unregistering the extension (first unregistration will remove the extension), but this is really non-issue with 4.x because in most cases we expect the "static" order to be defined in the MainDeployer xmbean config.

This will be probably different in next gen (i.e. no static override)