JBAS-7469, move bootstrap class loading into profile

[starksm64]

The last piece of the legacy conf/jboss-service.xml that needs to be removed in order for the profile bootstrapURI to be dropped along with this service descriptor is the:

 <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
 the shared JBOSS_HOME/common/lib directory. This can be restricted to
 specific jars by specifying them in the archives attribute.
 TODO: Move this configuration elsewhere
 -->
 <classpath codebase="${jboss.server.lib.url}" archives="*"/>
 <classpath codebase="${jboss.common.lib.url}" archives="*"/>

I think this sould be part of the profile definition metadata and the current bootstrapURI processing replaced with the setup of a class loader bean deployment. I wanted to look more at the current bootstrap/embedded/shrinkwrap projects to what requirements exist along these lines.

[alrubinger]

EmbeddedAS is a bit of a different beast. Currently it has a mega-JAR of all AS dependencies bundled for users to put on the ClassPath. Looking forward I need to intelligently trim this down so that user tests can still use the APIs without leaking internals and resulting in NoClassDefFoundError when AS comes up. So in effect, when AS starts up in Embedded mode, all classes are loaded from the application CL.

From the perspective of the bootstrap project, ClassLoading is removed from scope entirely except for this bit which Adrian has wanted to move out for some time:

http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-base/src/main/java/org/jboss/bootstrap/impl/base/server/AbstractServer.java @startBootstraps()

...where we rely upon the CL which loaded the bootstrap to start processing its referents. Everything else is set up by Main in phases (appCL slim run.jar, then we add a custom URLCL with a bunch of things necessary to start the server).

ShrinkWrap won't be at all affected.

But let me know if you run into more specific issues.

[emuckenhuber]

I think this sould be part of the profile definition metadata and the current bootstrapURI processing replaced with the setup of a class loader bean deployment. I wanted to look more at the current bootstrap/embedded/shrinkwrap projects to what requirements exist along these lines.

Hmm yes i was thinking about adding additional information to the profile meta data as well - also related to virtual deployments. So it could make sense to do something like that replacing that.

In a different thread you were mentioning that deploy/ is a mess. It looks like the same is true for the common.lib folders as well. Most of the .jars would actually rather belong to a deployer or profile. Especially since classloading needs to process around 20MB everytime AS is started. This however seems to require moving more jboss deployments to a common location so that the distribution does not get too big.

[jaikiran]

"emuckenhuber" wrote:
It looks like the same is true for the common.lib folders as well. Most of the .jars would actually rather belong to a deployer or profile.

I agree with this point. For example, the EJB3 jars would make sense only for a profile which has EJB3 capabilities. Right now most of the EJB3 jars are put in common/lib.

[starksm64]

Ultimately there should just be a repository that serves all artifact contents, be it library jars, server deployments, etc. Right now the problem is that the server install structure is a reflection of the repository. There should be a disconnect between the repository store, and what actually is getting pulled into the bootstrap classpath. The deployments should just have references to the package dependencies which are then resolved from the repository.

In terms of the messiness of the directories, its mostly just an issue of needing to have client facing variations so that they know where to put libraries and deployments without worrying about how it affects the server class isolation as well as knowing what customization they have made.