You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@coredevelopers.net> on 2003/09/07 01:53:11 UTC
[moving-code] Boot time services to kernel module
Unless someone objects. I'm going to move the boot time services code
to the kernel module. The main motivation for this is the current
class loading is broken because the geronimo-core jar is booted on the
system class path so any service in core must have all of the classes
it depends on in the system class path.
I am defining any boot time services as any code necessary load an
empty boot-service.xml file. Since the boot-service.xml file can
define a class loader for the service in the file, we don't need to
include anything extra. This will include the Main class and most of
deployment.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] Boot time services to kernel module
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Monday, September 8, 2003, at 05:52 AM, Jason Dillon wrote:
>>> Collections are your friend too ;-) ReferenceMap makes it super
>>> simple ti write memory friendly caches and such.
>>
>> Actually it is not by the fact to use a single class from the package
>> you have to suck down a half meg jar.
>
> Me thinks XDoclet plugin makes uses of it and I am using ReferenceMap
> in my alpha task based MBeanProxyFactory to make the task cache memory
> friendly for the vm. I think as we add new services that we will and
> to use more from commons-collections.
I forgot to mention that Jeremy and I wrote a ReferenceMap while
writing the cache code for Geronimo and it took all of 15 minutes.
>>> I would really not worry too much about the base size right now. If
>>> it comes down to it we can scape out the goodies we need into a
>>> smaller archive, but that is just more work and not worth it right
>>> now IMO.
>>
>> I disagree now is the time before things get too highly coupled (and
>> trust me I know things are very highly coupled right now).
>
> Decoupling is good, though lets not be to excessive about it right now
> is what I am saying. If in the end we find that only n classes are
> used from a common jar, then we can suck them out from the standard
> dependencies and ad make micro versions for releases.
I dislike that idea, because it makes our build brittle.
> BTW, why did the log bits get dropped back into the kernel module?
I would have liked to keep put it in core, but the commons logging
framework has a flaw where once it chooses a log implementation there
is no way to change it. If we can get them to allow us to swap out the
log implementation at runtume, we can boot with the default Log4jLog
(or even JDK 1.4 logging) and latter when our Log management service
starts we could switch to the caching log4j log.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] Boot time services to kernel module
Posted by Jason Dillon <ja...@coredevelopers.net>.
>> Collections are your friend too ;-) ReferenceMap makes it super
>> simple ti write memory friendly caches and such.
>
> Actually it is not by the fact to use a single class from the package
> you have to suck down a half meg jar.
Me thinks XDoclet plugin makes uses of it and I am using ReferenceMap
in my alpha task based MBeanProxyFactory to make the task cache memory
friendly for the vm. I think as we add new services that we will and
to use more from commons-collections.
>> I would really not worry too much about the base size right now. If
>> it comes down to it we can scape out the goodies we need into a
>> smaller archive, but that is just more work and not worth it right
>> now IMO.
>
> I disagree now is the time before things get too highly coupled (and
> trust me I know things are very highly coupled right now).
Decoupling is good, though lets not be to excessive about it right now
is what I am saying. If in the end we find that only n classes are
used from a common jar, then we can suck them out from the standard
dependencies and ad make micro versions for releases.
BTW, why did the log bits get dropped back into the kernel module?
--jason
Re: [moving-code] Boot time services to kernel module
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Sunday, September 7, 2003, at 04:16 AM, Jason Dillon wrote:
>> I would love to get rid of commons-collections because it is a pig,
>> but digester uses one class from it.
>
> Collections are your friend too ;-) ReferenceMap makes it super
> simple ti write memory friendly caches and such.
Actually it is not by the fact to use a single class from the package
you have to suck down a half meg jar.
> I would really not worry too much about the base size right now. If
> it comes down to it we can scape out the goodies we need into a
> smaller archive, but that is just more work and not worth it right now
> IMO.
I disagree now is the time before things get too highly coupled (and
trust me I know things are very highly coupled right now).
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] Boot time services to kernel module
Posted by Jason Dillon <ja...@coredevelopers.net>.
> I would love to get rid of commons-collections because it is a pig,
> but digester uses one class from it.
Collections are your friend too ;-) ReferenceMap makes it super simple
ti write memory friendly caches and such.
I would really not worry too much about the base size right now. If it
comes down to it we can scape out the goodies we need into a smaller
archive, but that is just more work and not worth it right now IMO.
--jason
Re: [moving-code] Read Me
Posted by Dain Sundstrom <da...@coredevelopers.net>.
I forgot to mention that I didn't move any test cases. It was too much
to get this stuff to work and move all the test cases also. Please
check that your test cases are in the correct module.
I also had to disable the MBeanProxy tests, because I could not figure
out how they worked (at 1 am). I apologize to whom ever wrote this.
-dain
On Monday, September 8, 2003, at 01:32 AM, Dain Sundstrom wrote:
> This done now. I strongly suggest you update your source tree right
> away as a ton of code has moved.
>
> We now have a kernel module that depends on no other modules on
> geronimo. It has a 3MB footprint right now, but I think we can get it
> down to under 1.5MB without sacrificing and functionality. The boot
> time required jars are now put in a bootlib directory (until jason
> finds a better place for them).
>
> I think we need to quickly breakup the core module as it is getting
> highly coupled. Also, we need to keep tighter control on the common
> module. This module should be reserved for truly cross cutting
> concerns and truly tricky code. It it is not really common code it
> shouldn't be in common and if it is easy code, we are better off
> keeping it in the classes that would have used it and avoiding the
> coupling. The kernel module should also be keep very clean, as it
> directly effects our ability to be used in small utility command, our
> embedability and boot time.
>
> Anyway, take a good look at the new layout, and speak up if you don't
> like some of my changes. It you want to run the server use "maven
> run:main".
>
> -dain
>
> On Sunday, September 7, 2003, at 01:39 AM, Dain Sundstrom wrote:
>
>> Of course this turned into a massive effort... A list of the all of
>> the code moved from core follows:
>>
>> Moved to common module
>> ----------------------
>> o.a.g.common.jmx
>> AbstractMBeanProxyHandler.java
>> DependencyService.java
>> JMXUtil.java
>> MBeanRelationship.java
>> Relationship.java
>> RelationshipMBeanProxyFactory.java
>> o.a.g.common.management
>> the entire package o.a.g.management except AbstractManagedObject
>> (we need this one here because boot services implement these
>> interfaces)
>> o.a.g.common.service
>> the entire package o.a.g.common from core module
>> AbstractManagedObject
>>
>>
>> Moved to kernel module
>> ----------------------
>> o.a.g.kernel
>> Main
>> o.a.g.kernel.deployment
>> the entire package o.a.g.deployment except model and repository
>> o.a.g.kernel.jmx
>> JMXKernel
>> GeronimoMBean* (I'm not sure about this one, but GermonimoMBean
>> uses o.a.g.k.d.DeploymentException)
>>
>>
>>
>> With this structure the we get a kernel that can boot with the
>> following jars:
>> commons-collections-SNAPSHOT.jar 464k
>> commons-digester-1.5.jar 108k
>> commons-jexl-SNAPSHOT.jar 112k
>> commons-lang-SNAPSHOT.jar 168k
>> commons-logging-1.0.3.jar 32k
>> geronimo-common-DEV.jar 172k
>> geronimo-kernel-DEV.jar 96k
>> log4j-1.2.8.jar 348k
>> mx4j-SNAPSHOT.jar 388k
>> xerces-2.4.0.jar 876k
>> xml-apis-1.0.b2.jar 108k
>>
>> Which is 2.8 MB total. I think we can remove the boot requirement on
>> xerces and the xml-apis which would put us comfortably under 2MB. I
>> would love to get rid of commons-collections because it is a pig, but
>> digester uses one class from it.
>>
>> I'm going to sit on these changes until noon tomorrow CST (about 10
>> hours from now), to give everyone due time complain.
>>
>> -dain
>>
>> On Saturday, September 6, 2003, at 06:53 PM, Dain Sundstrom wrote:
>>
>>> Unless someone objects. I'm going to move the boot time services
>>> code to the kernel module. The main motivation for this is the
>>> current class loading is broken because the geronimo-core jar is
>>> booted on the system class path so any service in core must have all
>>> of the classes it depends on in the system class path.
>>>
>>> I am defining any boot time services as any code necessary load an
>>> empty boot-service.xml file. Since the boot-service.xml file can
>>> define a class loader for the service in the file, we don't need to
>>> include anything extra. This will include the Main class and most
>>> of deployment.
>>>
>>> -dain
>>>
>>> /*************************
>>> * Dain Sundstrom
>>> * Partner
>>> * Core Developers Network
>>> *************************/
>>
>>
>
> /*************************
> * Dain Sundstrom
> * Partner
> * Core Developers Network
> *************************/
>
>
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] Read Me
Posted by Jason Dillon <ja...@coredevelopers.net>.
> The boot time required jars are now put in a bootlib directory (until
> jason finds a better place for them).
Will look into this shortly.
> I think we need to quickly breakup the core module as it is getting
> highly coupled.
Agreed.
> Also, we need to keep tighter control on the common module. This
> module should be reserved for truly cross cutting concerns and truly
> tricky code.
Agreed... mostly. Basically if 2 or more modules needs the same
functionality which can be packed up into a class it should be placed
in common. That was the whole point of common in the first place, to
avoid code duplication and to improve maintainability.
> The kernel module should also be keep very clean, as it directly
> effects our ability to be used in small utility command, our
> embedability and boot time.
Agreed, though I am worried that if we over minimize things it will
limit our ability to make use of tested and functional code that exists
already on the net. If it comes down to it I will write a maven goal
to suck out classes from jars to make mini jars with the required
functionality.
--jason
Re: [moving-code] Read Me
Posted by Dain Sundstrom <da...@coredevelopers.net>.
This done now. I strongly suggest you update your source tree right
away as a ton of code has moved.
We now have a kernel module that depends on no other modules on
geronimo. It has a 3MB footprint right now, but I think we can get it
down to under 1.5MB without sacrificing and functionality. The boot
time required jars are now put in a bootlib directory (until jason
finds a better place for them).
I think we need to quickly breakup the core module as it is getting
highly coupled. Also, we need to keep tighter control on the common
module. This module should be reserved for truly cross cutting
concerns and truly tricky code. It it is not really common code it
shouldn't be in common and if it is easy code, we are better off
keeping it in the classes that would have used it and avoiding the
coupling. The kernel module should also be keep very clean, as it
directly effects our ability to be used in small utility command, our
embedability and boot time.
Anyway, take a good look at the new layout, and speak up if you don't
like some of my changes. It you want to run the server use "maven
run:main".
-dain
On Sunday, September 7, 2003, at 01:39 AM, Dain Sundstrom wrote:
> Of course this turned into a massive effort... A list of the all of
> the code moved from core follows:
>
> Moved to common module
> ----------------------
> o.a.g.common.jmx
> AbstractMBeanProxyHandler.java
> DependencyService.java
> JMXUtil.java
> MBeanRelationship.java
> Relationship.java
> RelationshipMBeanProxyFactory.java
> o.a.g.common.management
> the entire package o.a.g.management except AbstractManagedObject
> (we need this one here because boot services implement these
> interfaces)
> o.a.g.common.service
> the entire package o.a.g.common from core module
> AbstractManagedObject
>
>
> Moved to kernel module
> ----------------------
> o.a.g.kernel
> Main
> o.a.g.kernel.deployment
> the entire package o.a.g.deployment except model and repository
> o.a.g.kernel.jmx
> JMXKernel
> GeronimoMBean* (I'm not sure about this one, but GermonimoMBean
> uses o.a.g.k.d.DeploymentException)
>
>
>
> With this structure the we get a kernel that can boot with the
> following jars:
> commons-collections-SNAPSHOT.jar 464k
> commons-digester-1.5.jar 108k
> commons-jexl-SNAPSHOT.jar 112k
> commons-lang-SNAPSHOT.jar 168k
> commons-logging-1.0.3.jar 32k
> geronimo-common-DEV.jar 172k
> geronimo-kernel-DEV.jar 96k
> log4j-1.2.8.jar 348k
> mx4j-SNAPSHOT.jar 388k
> xerces-2.4.0.jar 876k
> xml-apis-1.0.b2.jar 108k
>
> Which is 2.8 MB total. I think we can remove the boot requirement on
> xerces and the xml-apis which would put us comfortably under 2MB. I
> would love to get rid of commons-collections because it is a pig, but
> digester uses one class from it.
>
> I'm going to sit on these changes until noon tomorrow CST (about 10
> hours from now), to give everyone due time complain.
>
> -dain
>
> On Saturday, September 6, 2003, at 06:53 PM, Dain Sundstrom wrote:
>
>> Unless someone objects. I'm going to move the boot time services
>> code to the kernel module. The main motivation for this is the
>> current class loading is broken because the geronimo-core jar is
>> booted on the system class path so any service in core must have all
>> of the classes it depends on in the system class path.
>>
>> I am defining any boot time services as any code necessary load an
>> empty boot-service.xml file. Since the boot-service.xml file can
>> define a class loader for the service in the file, we don't need to
>> include anything extra. This will include the Main class and most of
>> deployment.
>>
>> -dain
>>
>> /*************************
>> * Dain Sundstrom
>> * Partner
>> * Core Developers Network
>> *************************/
>
>
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] Boot time services to kernel module
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Of course this turned into a massive effort... A list of the all of the
code moved from core follows:
Moved to common module
----------------------
o.a.g.common.jmx
AbstractMBeanProxyHandler.java
DependencyService.java
JMXUtil.java
MBeanRelationship.java
Relationship.java
RelationshipMBeanProxyFactory.java
o.a.g.common.management
the entire package o.a.g.management except AbstractManagedObject
(we need this one here because boot services implement these
interfaces)
o.a.g.common.service
the entire package o.a.g.common from core module
AbstractManagedObject
Moved to kernel module
----------------------
o.a.g.kernel
Main
o.a.g.kernel.deployment
the entire package o.a.g.deployment except model and repository
o.a.g.kernel.jmx
JMXKernel
GeronimoMBean* (I'm not sure about this one, but GermonimoMBean
uses o.a.g.k.d.DeploymentException)
With this structure the we get a kernel that can boot with the
following jars:
commons-collections-SNAPSHOT.jar 464k
commons-digester-1.5.jar 108k
commons-jexl-SNAPSHOT.jar 112k
commons-lang-SNAPSHOT.jar 168k
commons-logging-1.0.3.jar 32k
geronimo-common-DEV.jar 172k
geronimo-kernel-DEV.jar 96k
log4j-1.2.8.jar 348k
mx4j-SNAPSHOT.jar 388k
xerces-2.4.0.jar 876k
xml-apis-1.0.b2.jar 108k
Which is 2.8 MB total. I think we can remove the boot requirement on
xerces and the xml-apis which would put us comfortably under 2MB. I
would love to get rid of commons-collections because it is a pig, but
digester uses one class from it.
I'm going to sit on these changes until noon tomorrow CST (about 10
hours from now), to give everyone due time complain.
-dain
On Saturday, September 6, 2003, at 06:53 PM, Dain Sundstrom wrote:
> Unless someone objects. I'm going to move the boot time services code
> to the kernel module. The main motivation for this is the current
> class loading is broken because the geronimo-core jar is booted on the
> system class path so any service in core must have all of the classes
> it depends on in the system class path.
>
> I am defining any boot time services as any code necessary load an
> empty boot-service.xml file. Since the boot-service.xml file can
> define a class loader for the service in the file, we don't need to
> include anything extra. This will include the Main class and most of
> deployment.
>
> -dain
>
> /*************************
> * Dain Sundstrom
> * Partner
> * Core Developers Network
> *************************/