I forgot to remind everyone of the point behind these apparently fragmented service.xml files....
They enable easy deployment/undeployment of large chunks of server functionality (including replacing the classes implementing the functionality) WHILE THE SERVER IS RUNNING. In 2.4, to add a datasource non-programatically you had to modify jboss.jcml, stop jboss, and restart. Now you can just drop a mydb-service.xml file in deploy, and away you go. I think most of the problems people are having are because there is no documentation other than my off the cuff responses to questions and because the current service.xml files are extremely disorganized. The base jboss-service.xml file includes zilliions of jars it isn't using, just becasue they were in marc's lib/ext when he first wrote the example, and I haven't modified or written the appropriate service.xml for the chunk of functionality exposed. For instance, I think it makes sense to put the castor adapter mbean and the castor jar in a sar, and remove all reference to it from the base jboss-service.xml. To get castor, you add the sar. If you don't want castor, you wont have extra classes loaded. david jencks <big snip> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
