Most services using the conf directory are just doing a ClassLoader.getResource() soThis is asking for a configuration service. The notion here of merging overrides based on speical URLs has too many implementation requirements.
What do you mean?
overriding the conf with a user specific one means there is a directory in
the classpath search order ahead of the default. This places restrictions on
the class loader implementation, and if you are talking about allowing for merging of resources ala JNDI InitialContext, using the classpath is a error
prone solution.
This is revolutionary change to the BM. The specification of the data users can provide is not independent from the engine configuration. You cannot do the "tomcat port is 80 and its logging level is bla" config today because the logging level has not been defined as settable via the BM.
Yes, but this information could be extracted from a standard meta-data file that could be provided by the service in itself (or its DD). For simple engine, the attributes that can be overriden are the mbeans attributes whereas for more complex engines, "this" should be provided by the service. "this" means both the XSLT engine configuration AND the list of "attributes".
Right, but the point is, what data is available to set by the end user depends on this service level metadata. This ultimately either entails looking at what xsl variables are being used or yet another level of metadata that defines the implicit attributes used in nested configurations. The latter is required as well for any admin console that is going to provide a meaningful view into the configuration of a non-trival mbean like the web container.
I don't disagree in general with what you are driving at, but this is well outside of the scope of a 3.2 release, so what is the plan for introducing these changes? Its arguable that any of this can be done short of a major release.
Most of these changes could be transparently added to 3.2, while others may have to wait for 4.0. My point is first to find a "path" where we think JBoss config should go and then we can decide how to map it to the release agenda.
Cheers,
sacha
I agree there needs to be a roadmap, I don't agree that these are transparent changes that can be added to 3.2.
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
