> We already have this capability, its just a question of using
> it. The hsqldb-ds.xml can reference a
> <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.
Yes, I am not saying that nothing is there and everything must be
reimplemented. Some of my suggestions are simply about better usage of the
current JBoss possibilities. This is mostly DD cleanup and extracting these
JARs from the straight lib that is read by conf/JBoss-service.xml
> > 2) /conf
> > ========
...
> > 1) conf files
> > 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.
What do you mean?
> > 2) jboss-service.xml
...
> > 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...)
> >
> This is a change in the notion we have put forth for the
> conf/jboss-service.xml 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.
Yes, that is the point: "not having to modify the configuration to collect
the user defined overrides"
> > 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.
Yes.
> > - Binding Manager Extensions
...
> > 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.
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".
> > - Service *definition* vs Service *activation* As
...
> > This "Activation Manager" (AM) service could simply be an
> extension of
...
>
> 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
-------------------------------------------------------
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
