Again for those that missed it... --jason
-------- Original Message -------- Subject: Embedable, ServerLoader, jboss-boot.jar, logging and more... Date: Sun, 24 Feb 2002 03:37:31 -0800 From: Jason Dillon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] With the seperation changes also come the first major embedable change that I was planning, which was the introduction of the ServerLoader component. SL performs similar functionality as the newly added Boot utiltiy, but provides a JBoss specific interface with the sole purpose of loading the central Server component (which sets up the GPA/MicroKernel/Core system). jboss-boor.jar contains all of the required files to bootstrap (load and start) the Server component. It contains Server, ServerConfig and ServerLoader and is about 5k (with javac.debug=true). It provides a raw API to load, initialize and start a Server instance. ServerLoader accepts a parent CL for delegation, per Scott's list. To help keep things small, Server and ServerConfig have been turned into interfaces. I have provided implemeations for both as ServerImpl andf ServerConfigImpl, which perform the same basic functions they did before. MBean interfaces are also provided for these. To further keep things small (as well as expose more control to clients), server configuration is now initially property based. I followed the InitialContext aproache read config properties from a passed in Properties map. Cleints can create a map that will default to System.getProperties() thus allowing more control over how the server is configured. For example to change the temporray dir that is used by default, the client would: props.setProperty(ServerConfig.TEMP_DIR, "/some/path/tmp"); or on the command line (via Main): ./run.sh -Dorg.jboss.system.server.temp.dir=/some/path/tmp Defaults are still constructed in the previous value, only ServerConfig.HOME_DIR needs to be set, everything else can be calculated from there. See the javadoc for Server & ServerConfig for more information. I said that config is initially property based, as once the Server impl is loaded a typed adapter (ServerConfigImpl) is created to allow typed access to the values provided here (and thus keeping clients from having to perfrom the same redundant data conversion). Since all (practically) libraries are now loaded off network and the classes on the system classpath have been minimized, the utility of a lib/ & lib/ext seperation (as well as spineURL and such) have deminished. I have removed usage of these to reduce complexity. All library files go into lib/ now. Now that we can load log4j from the network durring bootstrapping, the core components now make use of it directly instead of using BootstrapLogger. A default log4j.properties file is provided in run.jar whichs sets up the default enviroment. Users can override this behavior by using log4j specific configuration. Log4jService still allows the config file to be read from system properties though. Javadoc in Main shows how todo this. May want to provide a default debug config in run.jar to avoid needing to append to the classpath... Since the core components now use log4j Main had to be updated to use the ServerLoader. I added a few more command line options to expose more control by allowing extra libraries and classpath URs to be specified. This is mostly to allow the above log4j override bits to work as well as allow any JAXP or JMX impl to work. Only crimson and xerces are supported by the --jaxp option, but by specifing the extra libs and the full jaxp factory impl properties on the command line any jaxp parser can be used. Same goes for JMX, right now only the RI is available, but if you specify the lib of another it will be prepended to the classpath and thus used first. To top things off Server will now append org.jboss.net.protocol to the protocol handler list, making these protocols available to the entire server. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
