One thing we really need to be careful with is what happens when JARS are analyzed.

For instance, EJB3 requires a ".ejb3" filename extension because it has to iterate the entire archive and look at every single class in that archive for annotations that may be EJB3 annotations. If ".jar" files were accepted as well, it would have slowed down the deploy process significantly.

There should be no need for such hardcoding.

The problem with the old jar deployer was
1) There was no ordering of deployers when it did accepts()
2) It was first to recognise it wins
3) The deployers were loaded in an adhoc fashion

With the new deployers, the structural component that analyses the structure
will be ordered (still with first to recognise it wins).
Also, the structural deployers will be amongst the first things to be deployed.

i.e. we don't have to worry about the jar deployer stealing a war deployment
inside a sar because its sar was processed before the tomcat sar.

The only way it is not going to work is if you don't have a war deployer.
In that case, the jar deployer will be the only one that recognises the deployment.

I don't see that the JARDeployer has any reason for existence. If there is referenced content that has no associated deployer it should not just be added to some classpath. The configuration of the class and resource paths is an aspect of some deployment.

Yes, but you need something to add plain jars and directories to the classpath.

I believe it should be a policy decision whether it just does it or whether it looks
for specifc pattern (like does it end with .zip or .jar, etc.)

In the current implementation it just does it (with some file patterns excluded by
the deployment scanner not the deployer framework).

But that something should be the configuration of another service like the bootstrap service, or even the URLDeploymentScanner.