So the simplest thing todo here is to simply not unset the cl used to
load the server with. I am not sure this is the best way to fix this
but should work. Let me know if you still have trouble.
--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
