I see what you mean now... trying to think of how to fix this though.
Could hide init inside of ServerLoader, could pass Server impl the CL
or could expose the CL to SL caller.
This CL stuff is messy...
--jason
Adrian Brock wrote:
>Hi Jason,
>
>I've got a problem integrating JBossMX with your
>new Server code.
>
>In ServerLoader.load(ClassLoader) you construct a
>URLClassLoader and set it as the TCL (Thread class loader).
>This is for dynamically loading classes from
>configuration options.
>
>But Server.start() does not have this TCL.
>We do the same config processing in JBossMX,
>we can't find the classes during
>MBeanServerFactory.createMBeanServer("jboss") :-(
>
>Looks pretty good besides.
>
>P.S. You misspelt DEFUALT_BOOT_LIBRARY_LIST :-)
>
>Regards,
>Adrian
>
>>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,
>>R, "/some/path/tmp");
>>
>>or on the command line (via Main):
>>
>>./run.sh
>>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-dev
>>lopment
>>
>
>
>
>_________________________________________________________
>View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=9653
>
>_______________________________________________
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
