A detail in my original post that I didn't emphasize enough and that might have significant implications: there's a difference in URIs associated with the root profile metadata in my StaticClusteredProfileFactory above and the StaticProfileFactory currently in trunk. In StaticProfileFactory, the profile metadata URIs point to the application URIs, e.g. the deploy/ dir: | protected void createProfileMetaData(ProfileKey rootKey, URL url) throws Exception | { | ...... | | // Create root profile; | URI[] rootURIs = applicationURIs.toArray(new URI[applicationURIs.size()]); | String[] rootSubProfiles = new String[] { BOOTSTRAP_NAME, DEPLOYERS_NAME }; | ProfileMetaData root = createProfileMetaData( | rootKey.getName(), true, rootURIs, rootSubProfiles); | // Add to profile map | addProfile(rootKey, root); | } | In StaticClusteredProfileFactory above, the application URIs are associated with an APPLICATION subprofile; the root profile itself doesn't have any URIs, just subprofiles. I think this approach is more consistent with how it will work when we shift to something like XmlProfileFactory. My concern is that the StaticClusteredProfileFactory approach can break DeploymentManager or ManagementView in AS 5.1, i.e. if those implementations will be counting on an implementation detail that they can load, for example, the "all" profile and then copy content to it's URIs. They would need to access the "all" profiles APPLICATION subprofile and copy content there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213052#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...