JBoss uses log4j, which uses a properties file or XML file for its configuration. However, you can go into your jmx-console and use the Log4jService to reconfigure log4j. I am not sure how they did this, but I think its a good example of using MBeans to manage third party library configuration.
To your point about testing, I have no good answer... I am just starting with JMX myself and have not figured out automated testing yet.
If this is a development box you are using, you could write a quick ant target that packages up your properties into a jar and copies it to the JBoss deploy directory. Not sure how this will work with the loader repositories.. you may have to do some classloader voodoo.
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
David Corbin wrote:
I'm not very educated on EJBs (in any form), but I tend to resist them as they make automated testing a lot more complex. And, often the configuration is for a piece of code that I don't have control of (i.e, a third party library that relies on a properties file, or an XML file of some sort).
David
Ryan Hoegg wrote:
This may be a sledgehammer for your thumbtack, but you could redesign your configuration system to use JMX MBeans.
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
David Corbin wrote:
Please feel free to tell me I'm nuts, or that there is a better way to solve my problem.
I'd like to have a directory that is "recognized by a class loader as if it were on the class path", that is intrinsicly associated with a .WAR (I can't speak to .EAR, though that might be good too). Here's why:
I package my web application in .WAR file, and I distribute that application that way. When I want to tweak a confiugration, I have to unjar-edit-rejar the .WAR file. I really find this very annoying and prone to mistakes when different systems need to have different configurations. If I could have a directory in "deploy" that was automatically associated with different .WAR files, managing configuration issues would be much eaiser. Say "foo.war.classes" for "foo.war". Since, as I understand it, JBoss provides a class loader, I would think it is just a question of making that class loader a little smarter.
David
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
