Rationalization of our deployment directory

[starksm64]

I was looking at our deploy directory in trunk and its a mess. Certainly a lot of legacy stuff that should be optional, but in general profile specific server extensions. We have touched on having multiple deploy directories in the past, and its time we work toward that as well as defining proper class loading imports/exports for the deployment artifacts shipped with the server. I would like to see two basic directories:

services - jboss services for the profile
deploy - user applications

The expectations of content in deploy is that they can customize allowed apis such as logging, xml parsers, implementation details of specs the profile supports (jpa provider, jsf, ...) without out containers blowing up. We now have a class loader model capable of handling this, so let's make that a reality.

This issue is being tracked by the TAG as https://jira.jboss.org/jira/browse/TAG-12

[starksm64]

"bburke" wrote:

This is something that should probably be discussed on dev lists, but what I'd *really* like to see is configuration enclosed in "super* jars and totally hidden. Use classpath to resolve config files. This allows us to have a common default that can be overriden by user easily just through the classpath. Would also help out embedded implementation.