We really need to decide what we are going to do about the classloader
the deployers run under.
In the old system everything ran under the conf/jboss-service.xml
classloader which has a hook into the ULR.
In the new system, we try to emulate this, but the profile service allows multiple
bootstrap deployments so we just choose the "first one".
This is obviously very hacky.
But this isn't going to work with the OSGi style classloading.
If the deployer's deployment doesn't export its deployment classes,
the conf/jboss-service.xml classloader won't be able to see them.
You'd have the same problem if a deployer was scoped with the ULR.
What we really want is for each deployer to run under its own classloader,
i.e. the one of the deployment where is was deployed.
Assuming we do that, there's still the issue of what classloader the bootstrap
runs under.
In practice, the bootstrap classloader shouldn't be much of a problem.
It should only be in play while the main deployer (structural and normal deployers)
are determining what deployers to invoke.
So we could just run it under the real bootstrap classloader, i.e. the one
created by the ServerLoader?
I think this would just require moving things like some of the dtds and schemas
into the relevant jar, instead of them all being jboss.jar
