Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging and more...]

[Hiram C. <coj...@ho...>]

That's an even better solution!

Regards,
Hiram

>From: Jason Dillon <ja...@pl...>
>To: Hiram Chirino <coj...@ho...>
>CC: jbo...@li...
>Subject: Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, 
>logging and more...]
>Date: Tue, 26 Feb 2002 21:21:40 -0800
>
>Why don't I just have the Server use getClass().getClassLoader() and
>forget about exposing this as API?
>
>--jason
>
>
>Hiram Chirino wrote:
>
>>That does not sound right to me either.  Why not make the Server aware
>>of the classloader that he was loaded from.  You could do a
>>server.setServerClassLoader( classLoader ); after the
>>Server server = (Server)type.newInstance();
>>line in createServer()
>>
>>Then the server would be able to set the TCL at the begining of the
>>start() method.
>>
>>Regards,
>>Hiram
>>
>>
>>>From: Jason Dillon <ja...@pl...>
>>>To: jbo...@li...
>>>Subject: Re: [JBoss-dev] [Fwd: Embedable, ServerLoader,
>>>jboss-boot.jar, logging and more...]
>>>Date: Tue, 26 Feb 2002 20:47:45 -0800
>>>
>>>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 <ja...@pl...>
>>>>>To: jbo...@li...
>>>>>
>>>>>
>>>>>
>>>>>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
>>>>>Jbo...@li...
>>>>>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
>>>>Jbo...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/jboss-development
>>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Jboss-development mailing list
>>>Jbo...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>>
>>
>>
>>_________________________________________________________________
>>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com