Sacha Labourey wrote:
1) /libWe already have this capability, its just a question of using it. The hsqldb-ds.xml can reference a
=======
/lib is maybe the easiest case: it mostly contains JBoss's needed classes.
One small problem maybe: some of these classes are not directly use by the JBoss microkernel directly (nor by the services in conf/JBoss-service.xml) but by services that will be later deployed in /deploy (such as hsqldb-ds.xml). Consequently, if I later decide not to use HSQLDB by removing that service definition from "/deploy", I still have HSQLDB classes in my classpath. The risk is to overload the classpath with unnecessary classes and maybe generate class version problems: if I want to deploy my OWN version of HSQLDB, removing hsqldb-ds.xml from /deploy and putting "myOwnHSQLDBService.sar" in deploy is not enough, I will have to remove hsqldb.jar from /lib.
Suggestion: we may want to reduce what we put by default in /lib or have some kind of conditional loading i.e. we could put JARs such as hsqldb.jar in /lib/cond and have this JAR extend the classpath ONLY IF a service definition contained a "<classpath codebase="lib/cond" archives="hsqldb.jar"/>"
That way, if we use HSQLDB, this JAR will extend JBoss classpath, otherwise it will not.
<classpath codebase="lib/hsql" archives="hsqldb.jar"/>
There is no reason to add new semantics to the current classpath element.
There are new semantics in terms of identity of classes by virture of the
fact that the hsqsdb.jar classes are now associated with the hsqldb-ds.xml
deployment rather than the conf/jboss-service.xml deployment.
2) /conf ======== This directory is intersting for two reasons: 1) because it is part of the classpath and thus used by many services to load their configuration file(s) 2) because it contains the JBoss-service.xml file that will bootstrap JBoss.
1) conf files Concerning the first reason (contains configuration files), the problem is that if I am not happy with a default configuration file (log4j.xml, jbossmq-state.xml, jacorb.properties, etc.) I can modify it but will have a merge problem once I want to upgrade to a newer version of JBoss. So the question is: how may I override these files without having to merge later when uprading.
One solution would be to have JBoss use a JBOSS_CONF environment variable that would point to a folder ("server/xxx/user" by default) and this folder would be BEFORE "server/xxx/conf" on the classpath. Consequently, if log4j.xml is redefined (i.e. exists) in JBOSS_CONF, it is used, otherwise the default server/xxx/conf/log4j.xml file is used. When upgrading to a new release of JBoss, you can either re-copy your "server/xxx/user" directory from one release to the other or simply do nothing if JBOSS_CONF is defined by the developer and targets a directory OUTSIDE JBoss directory structure.
This is asking for a configuration service. The notion here of merging overrides based on speical URLs has too many implementation requirements.
This is a change in the notion we have put forth for the conf/jboss-service.xml2) jboss-service.xml This file contains the default services that any JBoss instance "should" need. Some of them are obvious (logging), some others are questionnable outside an EJB server (EJBDeployer) and some others are really questionnable as JBoss could very well run without them (invokers, bsh-deployer). Ideally, this file should contain the REALLY minimal set of services AND be self-sufficient (if you don't start anything else, JBoss shouldn't complain - which wasn't necesarly the case in the past: some version of JBoss would throw exceptions with an empty /deploy folder, as deploy/jboss-jca.sar was required...)
file as the statically defined services. What 'should' be needed is arbitrary,
and some of what is needed like the currently hard-coded MainDeployer, SARDeployer, ServiceController, etc should be externalized. You argument for
minimization has to do with not having to modify the configuration to collect
the user defined overrides. This gets to the point of seperating service
definition from activation.
Consequently, I think that the binding manager service should be started by default (possible conditionnaly using some command line arguments or environment variables) and be able to target a different file that could be either in JBOSS_CONF or specified on the command line. Whatever: we shouldn't have to modify JBoss-service.xml in order to override that file.
NOTE: One hypothesis that I did in this /conf/JBoss-service.xml section was that this file was so minimal that the developer will never want NOT to start one of its services. I will not make that hypothesis in the next section (about "/deploy").
So you are promoting the binding service as the source of service configuration information. The location of the service file can be externalizable via a system property by specifying its name as the StoreURL attribute value. It seems that this service will need to evolve to support a heirarchy of config info or else you are back to the user having to update the default settings shipped with the distribution.
- Binding Manager Extensions First, let's talk about the BM. The current BM has a set of "engine" (xslt, simple attribute). Each time a service is started, the BM checks if he has to overide some parameter. Furthermore, this file can contain configuration for more than one server. This is great. The problem is that this file not only contains the actual attribute overriding (i.e. "port must be 4444 instead of its default value", but also (possibly) the configuration of this overrriding (for XSLT for example). This should be somewhere else IMHO. Why not as part of the service definition in itself! (Mbean metadata for example): the service definitino would not only defines the set of DEFAULT attributes but also how THESE can be easily overriden by the BM by providing their own engine configuration (xslt or anything else). At the end of the day, the BM configuratin file submitted by the user should only contain INPUT DATA to 1) a BM engine 2) a BM engine configuration specific for that service. The user is only interested in providing the INPUT DATA, not the BM engine or its configuration (as this is service specific). Consequently, the user should only say to the BM "tomcat port is 80 and its logging level is bla", but no more provide 25 lines of ugly XSLT.
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.
- Service *definition* vs Service *activation* As described above, once defined, a JBoss service (mbean) is also activated (created and started). IMHO, we should split both. In the current state, without trying to make a huge revolution, it means we could have something like the Binding Manager (let's call it "Activation Manager") but instead of being used to say "overide attribute X of service Y once it is created", it would say "don't start service X" or "never start service X". The first version ("don't start") is equivalent to the "manual" notion in Windows i.e. if another service requires it, you can start it, but don't start it AUTOMATICALLY. The second version ("never start") is equivalent to the "disabled" notion in Windows: even if some other services depend on this service, don't start it, that is a strict restriction.
This "Activation Manager" (AM) service could simply be an extension of the extended Binding Manager so that a single file could be used: - to disable JBoss default services - override JBoss default services
We already have an AM, its the ServiceController. We do not have a notion of controlling its behavior. Its seems that this is really what you are asking for.
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.
-- 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
