> Not to offend you, Jason, but where have you been for the past couple of > weeks? There has been a whole bunch of threads about deploying XMLs only, > getting rid of packaging hell, glueing descriptors together, etc. Perhaps, > the birds kept you away from e-mail :)
No worries; I am not offended. It is not that I have not noticed these threads, mostly not had the time to dig through them and interject my opinions. I have been working on build system and website fluff... I have seen email about using xslt, deploying xml and so on... but I am not sure that I have seen email about what I am thinking about exactly... leaning twords, but still missing something. Or perhaps I have missed something... could be. > And you are right, this is where this is heading to. From all you have > said, there seems to be one idea that has not been mentioned before, > namely, using the overrides of default configurations. Don't know if this > is a good idea, if you mean that there is a default and you just put > changes to it into your descriptor. It is better to be redundant in Take for example the MDB I was talking about. With the current system, to change the number of messages that will be processed concurrently, I would have to duplicate the entire MDB config in my descriptor. That is *a lot* of configuration, which may change as new features are added to the container and so on. All I really want todo is bind the MDB to JNDI, attach to a destination and specify the connection consumer properties. The rest of the config is very uninteresting to simply get it deployed (not that it could not be useful at some point... just not to get it working). The point I am trying to make is that unjar/edit/jar'ing files is a really shitty idea. I would not expect many administrators to deal with this. True they could use some GUI tool todo this, but I don't know many unix admins who will be too happy about that, especially when they need to fix something from an old vt100 console. I personally would like to have the ability to distribute an archive of code and support classes for a service or application, then provide an example configuration file and have users deploy them both together. I would rather they didn't mess with unjar/jar'ing the main archive all together. * * * I think that having a defaults/overrides configuration system would be very beneficial to providing simple service/application configuration... especially to new users who might get confused by some of the more advanced stuff. I would say that in at least 80% of the cases, users want the default configuration. I bet they would also like to not have to change there verbose configurations when they move from container version to container. The MDB configuration could be slightly (or widely) different from 3.0 to 3.1 and so on... especially for advanced configuration. We will probably want to keep the basics consistent so users don't have to change too much. > specifying full config rather than having to mess around with a 'shadow' > default and 'diff' config. Hrm... I would say it is more like oob configuration, where you enherit the default from your super config, then override the bits that you actually care about. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
