> persist any SPECIFIC settings made through the JMX agent and overlay > them on top of the DEFAULT settings contained in > .sar/META-INF/jboss-service.xml.
The system in 3.0 can not do this. And I am not refering to using the JMX agent at all. In my production usage of JBoss, I use ant to filter the config files to change all of the ports needed to run jboss. I wrote a simple jython based system which manages the configuration values that differ across configurations. This easily lets me control the config of my entire network. If I upgrade to 3.0 I now have to startup a JBoss node, deploy an archive which has improper config then goto the JMX agaent to fix it then redeploy. I don't understand why you want me to go to the JMX agent now instead of a .xml file. > but desist from the 'it's such a pain to unpack/repack' argument, > because, as we have shown, there is no need to repack. This unpacked deployables is a very recent addition to the system, which its impl has not been fully thought out nor fully tested. Thus I do not even consider it an option for 3.0 and was very surprised that it was added so close to a final release. Furthermore I would much rather maintain 2 files rather than an explosed archive. Do you think it is easier to manage an exploded archive of mixed typed files, or 2 files with a clear and distinct seperation of functionality and usage? If you prefer the exploded archive then why are you archiving them all all? This seems to be in contradiction with your reasons to archive them in the first place. I am arguing what is the average user going to want and need todo with these files when they download JBoss to evalutate or test the new version. They will need to change the config. With 3.0 we are making it much harder for these users to do this. So far the reasons for a single archive are valid for a small section of users who are advanced enough with their setup, have finalized their configurations and are packaging up there services to make distribution easier or more managable. I would imagine that almost 100% of these users will need to change the config anyways. So that leaves the situation down to those who download JBoss, start it up, hit the port on 8080 and then stop using it... which I hope is a very small section of users who download. So it appears that the use case for an all in one jar is directed at a very, very small secvtion of our intended user base... so why do it. * * * Blah... sorry... this is stiring a fire inside of me. It seems so plain and obbvious to simply have a .sar and and .xml It works, it covers a much wider percentage of target users, it reduces the complexity to change the config, thus reducing the support questions and the complexity of the answers. No matter how you look at it, 2 files > one file > exploded archive with many files =[ --jason ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
