During my fresh and enduring experiences of porting the 3.0.4/3.0.8/3.2.1/3.2.2 to AIX 4.3.3 I have the feeling there should by a seperation between the TBB - to be build and tested - cycle, the configuration cycle and the lifecycle of the productive JBoss System as a whole: the enclosing cycle of both of the mentioned.
Not to talk about versioning the serveral build-and-run configs in the view of class-to-.?ar and .?ar-to-xml-tag mappings and dependencies for providing a real migration path with rollback options etc.
These are too complicated for the devel/support/service person, with so many different dependencies, to be handled manually. Starting from OS patchlevels, jdk's, resource restrictions like cpu load, ports and memory to the needs of the core system like jndi resources and clustering resources to the needs of application dependend jboss-localhost or remote db's and mq's.
If we where talking about the greenfield mill - no problem. But this is a very rare precondition ...
The preconditions are mostly already defined and read-only constraints. Reald world, you know.
What i have had build, if someone would pay for it - my client has the understandable opinion, that this should already provided by the container vendor - is a double-edged sword:
- build and test JBoss by JBoss in a mavenized manner (e.g. maven.apache.org) by a special configured JBoss
- use a XML repository for config-storage and config dependenciy auditing (e.g. Berkeley DB XML)
IMHO Sacha has grabbed a whale by the tail ;-)
bax
Am 08.11.2003 um 18:40 schrieb Sacha Labourey:
Hello,
I would like to continue our discussion of JBoss configuration as I think we
must make that much better for future releases of JBoss.
There are lots of facets to this problem but in order to keep things simply,
I would like to start talking about a single one: user configuration of
JBoss and migration to a newer minor release.
The rational behind this being: why do I need so much work when upgrading
between *minor* releases of JBoss and ZERO effort between migrating between
minor releases of mySQL, Microsoft IIS or PHP. Simply because the user
configuration is not mixed with code and service definition.
Use case:
=========
As a user of JBoss, I download a release of JBoss (3.2.1) and configure it
to fit my requirements: I add some services (JMS queues, data sources,
etc.), new applications (EAR, WAR, etc..), change some existing services
(update tomcat port, change jmx-console user/pass, etc.) and disable/remove
some default services (SNMP, HSQLDB, web-console, mail service, all JMX
invokers).
1 month later, I see that JBoss is just released with some great performance
improvments (thank's Bill, Scott and Adrian!). I download it and have to
play to a great game during 30 minutes: merge my current configuration of
JBoss with the new just downloaded 3.2.2.
Problem: the user configuration is tightly linked to JBoss itself. How to
have a loosly coupling between both?
JBoss Today: ============ Today, a resulting JBoss instance is defined by: 1) the JARs in /lib 2) some "static" configuration files in /conf 3) some "dynamic" services/applications in /deploy
Let's see what it means for our use case above.
1) /lib
=======
/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.
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.
2) 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...)
Once/if you have "purified" JBoss-service.xml (that contains the strict
minimum), the risk to have to change its content for your own needs is very
low. At most, you may want to change the port used by a service, or some
setting (such as the org.jboss.web.WebService:DownloadServerClasses
attribute).
So, to solve that problem, we can use the binding manager. Problems:
- it is not started by default (=> you have to ... Modify JBoss-service.xml
to use a service that will avoid to need to .. modify JBoss-service.xml...)
- if you start it by default, it will only try to find a single file (no
fall-back strategy) and thus will use a file that is part of the current
JBoss distribution, not your own configuration => you have to modify
JBoss-service.xml to target YOUR file
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").
3) /deploy
==========
Deploy is like the French kingdom in the late 18th: Deploy is king but
deploy is garbage (sorry to the royalists). The features that /deploy bring
(the URLScanner) are absolutly great, but this dynamicity has led to some
side-effects. At first, let's forget about applications (as they are mainly
deployed by developers anyway, not in the default JBoss deployment) and
let's focus on services.
Background for newcomers: services in JBoss are mainly deployed in two
different ways: xxxx-service.xml and myservice.sar (let's forget the
exploded archives, russian dolls and other derived solutions). The
difference between both being that one contains some classes while the other
doesn't. Such a deployment will possibly contain a classpath extension tag
(<classpath... />) and one or more service definition (<mbean ... > tags).
When a "macro-service" (such as something that is generally mentionned as
"the JMS server") is composed of sub-parts (or micro-services), we simply
put all these "micro-services" (i.e. Mbean definitions) that build the
global functionality in the same file (=> single deployment unit) and name
that file with an hopefuly readable name (jbossmq-service.xml).
The problem with our service definitions (xxx-service.xml) is that they
implicitly wrap several "features" that makes management harder at the end
of the day:
- classpath extension (when a SAR file): it means that if you modify the
configuration of such a SAR, when upgrading you will have to bring that new
configuration in the new SAR (because the code in the new SAR is most
probably more recent!)
- default configuration: each Mbean definition contains a set of
<attribute> tags that give the initial configuration to the service
- lifecycle: an mbean definition not only defines a new service as a CLASS
could be defined with its set of default parameters that SHOULD be used. No,
instead, it defines what this service should look like (yes) but also create
it and start it, directly!
Consequently, we don't have, on one side, a DEFINITON of what a set of
service COULD BE and on the other side the ACTIVATION (or non-activation!!)
of these services with (possibly) different attribute values. Furthermore,
we have a "granularity" issue as well: as the lifecycle is at the
micro-level (each mbean individually), it means nothing to say "stop
JBossMQ" as in facts the correct message would be "stop these 5 services in
that specific order". A possibility to wrap a set of micro-services behind a
single identity is lacking (from an administration standpoint).
What are the consequences of that? Let say:
- I want to change the value of an attribute for a service (tomcat port for
example): I have to either modify the tomcat-service.xml file (=> not
possible to easily transition to future versions of JBoss) or use the
binding-manger service. => The binding manager is potentially a good
solution, except that its current format is UGLY (if not more) for services
that have complex configurations (such as Tomcat). See below for "Binding
Manager Extensions" for a proposal.
- I want NOT TO START one of the default service of JBoss. In that case, I
have to remove it from the deploy folder. Problem: its classes may still be
in /lib and the migration between releases is not easy. Furthermore, if the
service definition is contained inside a xxx-service.xml file which contains
SEVERAL service definition, removing that file is not an option: I have to
modify it which makes the transition to newer release of JBoss even worst.
BTW, all these queues/topics that start as part of the JBoss startup are
NEVER used, except by ... the JBoss testsuite...
- I want to start additional services or application: in that case, I may
not want to drop them in the JBoss deploy folder because this is self
contained in a specific distribution which makes transition not easy.
Instead we may have deploy/system (for JBoss default services) and
JBOSS_CONF/deploy (which would fall-back on "deploy/user" if JBoss_CONF is
not defined). Whatever: the goal here is to be able to 1) split system and
user deployments 2) externalize user deployments 3) do it without having to
change conf/JBoss-service.xml (to add a new directory to the
URLDirectoryScanner for example). Everything should be done so that a
migration is smooth.
[ - I want to start additional services, such as JMS queues. The current
format, while good because generic, is also complex and requires many hard
to read tags. We could have specific deployment descriptors (like the
xxx-ds.xml format) for well-known deployments (such as queues, topics,
schedulers, etc.) This is a minor item as it is not a show-stoper for
transition between release of JBoss.]
- 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.
- 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
NOTE: the AM service could understand "*" convention and a specific JBoss
mode (command line) could have all JBoss services disabled by default (i.e.
"jboss*:*") so that if new services are available in a newer JBoss release,
it is not started (potential security breach) if not explicitly requested by
the developer)
Conclusion: at the end, the developer only needs:
- an "Activation Manager"/"Binding Service" configuration file
- a developer deploy folder (possibly different from the default /deploy
folder)
That can be used by any out-of-the box minor release of JBoss, no need to
edit anything: everything that is provided as part of JBoss is simply a
default configuration/code repository, not a definitive situation that can
only be changed by editing/removing them.
JBoss Tomorrow?
===============
There is much much more to say (how to deploy new services by wizard, how to
store configurations in a central repository, how to version
configurations), but let's keep it simply at first and start making JBoss
administration/configuration/evolution much easier. Please bring your
constructive input to that important matter.
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
------------------------------------------------------- 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
