PeterJ, Thanks for writing! My answers/reply inline: 1) You should not modify the configuration files in place while the application server is running. Instead, copy the one you want to modify to a temporary location, edit it there, and then copy back to deploy. Note that the files in server/xxx/conf are read only on startup. Not sure that you mean by "file system access", the app server needs access rights to all the configuration files. Excellent advice. Looking at the files in that directory, they don't appear to be application, connector, or datasource specific. I've noticed this about ./server/xxx/lib as well. 2) To deploy your own destinations, create a *-service.xml file, such as mydests-service.xml, and place the queue and topic descriptions in there. Copy the file to the deploy directory to deploy them, and delete it from there to undeploy them. Excellent. SO I can make as many as I like, providing they have the correct suffix. Is there a reference listing all of these file suffixes, and their corresponding applicability? It would be great to know which runtime config files can be added/removed like this! This is at the core of my question/problem. 3) I am not sure I understand what you are asking, but I think you want to deploy an exploded directory. You can then easily add/update/remove files in your application. See http://wiki.jboss.org/wiki/Wiki.jsp?page=ExplodedDeployment . The above is really the same as the below: 4) You can creat a JAR and deploy it programmatically, but I do not have an example. I was curious how to create stateful, statless, message-driven, and other beans programmatically, then deploy them programmatically as well. While I look for a solution to this dilemma, the above means to me that it is possible to access the JBoss file system (regardless of OS) from an application inside the container, right? Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044542#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...