Proposed plugin and clustering code/module rearrangement

[David Jencks <da...@yahoo.com>]

There are a couple code rearrangements I'd like to see before 2.1  
goes out.  I think they are somewhat related.

1. The plugin management code has been getting larger and more  
complicated and I think it should be in separate jar/car and the  
console support in separate cars.  I have the non-console bit of this  
working locally.  I have some of the jsr88 stuff wrapped up with the  
plugin stuff, and I believe the result is that you can construct a  
server with no ability to add or remove plugins or add or remove  
applications.  To me this seems like a very useful feature.

2. I think the "farm management" features of the clustering module  
should be separated from the clustering code and be available  
optionally independent of  whether clustering is enabled.  IMO the  
farm management features really only need the plugin management  
capabilities (I realize the farm management is not currently based on  
plugins, but think we need to consider whether it should be).

3. Jetty and tomcat now have some reliance on some base clustering  
classes which are only available in the clustering config.  I  think  
the base classes should be provided in e.g. j2ee-server and things  
arranged so that if you don't have the clustering config you don't  
get clustering, and if you do have it you do get clustering.  It  
might be that all the actual clustering gbeans could go into wadi- 
clustering, I haven't looked into this.

Thoughts?

thanks
david jencks

Re: Proposed plugin and clustering code/module rearrangement

[Gianny Damour <gi...@optusnet.com.au>]

On 11/01/2008, at 7:15 AM, David Jencks wrote:

> Could you update us on your guess for a time frame for the SFSB  
> clustering?  Will this require OpenEJB changes?  Is it realistic to  
> get this into 2.1?
Hello David,

I still target to complete SFSB clustering over the week-end. If this  
is not the case, then it will definitively be completed next week- 
end. This requires some OpenEJB changes: basically, a clustered  
stateful container is added and some SFSB related classes are updated  
to run passivation and activation logic when migrating SFSB instances  
from one node to another one.

I believe that if a 2.1 branch is ready to be cut, then it should be  
cut as soon as possible and not wait for the above stuff to be  
completed. The above stuff can be shipped as part of a subsequent 2.2.

>>>
>>> 3. Jetty and tomcat now have some reliance on some base  
>>> clustering classes which are only available in the clustering  
>>> config.  I  think the base classes should be provided in e.g.  
>>> j2ee-server and things arranged so that if you don't have the  
>>> clustering config you don't get clustering, and if you do have it  
>>> you do get clustering.  It might be that all the actual  
>>> clustering gbeans could go into wadi-clustering, I haven't looked  
>>> into this.
>> This is an approach.
>>
>> What do you think of this approach - for Jetty?
>> * create a new project plugins/jetty/geronimo-jetty6-clustering;
>> * move the package org.apache.geronimo.jetty6.cluster to this new  
>> project; and
>> * add a new dep. to jetty6-clustering-wadi.
>>
>> This way, the jetty6 config does not depend on clustering.
>
> I'll have to look at this more to understand it.  If you think it  
> solves the problem, please go ahead.
I have checked in the above approach early this week while working on  
a problem reported by Jarek. I think this solves the problem you  
reported.

I will now move the farm related classes as suggested.

Thanks,
Gianny

>
> thanks
> david jencks

Re: Proposed plugin and clustering code/module rearrangement

[David Jencks <da...@yahoo.com>]

Hi Gianny,  Happy New Year!

sorry for the delay in replying.

Could you update us on your guess for a time frame for the SFSB  
clustering?  Will this require OpenEJB changes?  Is it realistic to  
get this into 2.1?


On Jan 4, 2008, at 5:31 PM, Gianny Damour wrote:

> All, Happy New Year 2008!
>
> On 05/01/2008, at 9:10 AM, David Jencks wrote:
>
>> There are a couple code rearrangements I'd like to see before 2.1  
>> goes out.  I think they are somewhat related.
>>
>> 1. The plugin management code has been getting larger and more  
>> complicated and I think it should be in separate jar/car and the  
>> console support in separate cars.  I have the non-console bit of  
>> this working locally.  I have some of the jsr88 stuff wrapped up  
>> with the plugin stuff, and I believe the result is that you can  
>> construct a server with no ability to add or remove plugins or add  
>> or remove applications.  To me this seems like a very useful feature.
>>
>> 2. I think the "farm management" features of the clustering module  
>> should be separated from the clustering code and be available  
>> optionally independent of  whether clustering is enabled.  IMO the  
>> farm management features really only need the plugin management  
>> capabilities (I realize the farm management is not currently based  
>> on plugins, but think we need to consider whether it should be).
> This is a good idea. What do you think of moving  
> org.apache.geronimo.clustering.deployment+config, i.e. farm  
> management features and static cluster configuration classes, to a  
> new project, say clustering/geronimo-farm?

Insofar as I understand it I like it :-)
>
> Regarding the idea of basing the code on plugins, this is also a  
> good idea. However, I will not be able to work on that before a  
> couple of weeks as I would like to firstly complete the clustering  
> of SFSB (should be there end of next week) and load-time-weaving to  
> simplify delta replication.
>
>>
>> 3. Jetty and tomcat now have some reliance on some base clustering  
>> classes which are only available in the clustering config.  I   
>> think the base classes should be provided in e.g. j2ee-server and  
>> things arranged so that if you don't have the clustering config  
>> you don't get clustering, and if you do have it you do get  
>> clustering.  It might be that all the actual clustering gbeans  
>> could go into wadi-clustering, I haven't looked into this.
> This is an approach.
>
> What do you think of this approach - for Jetty?
> * create a new project plugins/jetty/geronimo-jetty6-clustering;
> * move the package org.apache.geronimo.jetty6.cluster to this new  
> project; and
> * add a new dep. to jetty6-clustering-wadi.
>
> This way, the jetty6 config does not depend on clustering.

I'll have to look at this more to understand it.  If you think it  
solves the problem, please go ahead.

thanks
david jencks

>
> If this is fine by you, then I am keen to do 2. and 3.
>
> Thanks,
> Gianny
>
>>
>> Thoughts?
>>
>> thanks
>> david jencks
>

Re: Proposed plugin and clustering code/module rearrangement

[Gianny Damour <gi...@optusnet.com.au>]

All, Happy New Year 2008!

On 05/01/2008, at 9:10 AM, David Jencks wrote:

> There are a couple code rearrangements I'd like to see before 2.1  
> goes out.  I think they are somewhat related.
>
> 1. The plugin management code has been getting larger and more  
> complicated and I think it should be in separate jar/car and the  
> console support in separate cars.  I have the non-console bit of  
> this working locally.  I have some of the jsr88 stuff wrapped up  
> with the plugin stuff, and I believe the result is that you can  
> construct a server with no ability to add or remove plugins or add  
> or remove applications.  To me this seems like a very useful feature.
>
> 2. I think the "farm management" features of the clustering module  
> should be separated from the clustering code and be available  
> optionally independent of  whether clustering is enabled.  IMO the  
> farm management features really only need the plugin management  
> capabilities (I realize the farm management is not currently based  
> on plugins, but think we need to consider whether it should be).
This is a good idea. What do you think of moving  
org.apache.geronimo.clustering.deployment+config, i.e. farm  
management features and static cluster configuration classes, to a  
new project, say clustering/geronimo-farm?

Regarding the idea of basing the code on plugins, this is also a good  
idea. However, I will not be able to work on that before a couple of  
weeks as I would like to firstly complete the clustering of SFSB  
(should be there end of next week) and load-time-weaving to simplify  
delta replication.

>
> 3. Jetty and tomcat now have some reliance on some base clustering  
> classes which are only available in the clustering config.  I   
> think the base classes should be provided in e.g. j2ee-server and  
> things arranged so that if you don't have the clustering config you  
> don't get clustering, and if you do have it you do get clustering.   
> It might be that all the actual clustering gbeans could go into  
> wadi-clustering, I haven't looked into this.
This is an approach.

What do you think of this approach - for Jetty?
* create a new project plugins/jetty/geronimo-jetty6-clustering;
* move the package org.apache.geronimo.jetty6.cluster to this new  
project; and
* add a new dep. to jetty6-clustering-wadi.

This way, the jetty6 config does not depend on clustering.

If this is fine by you, then I am keen to do 2. and 3.

Thanks,
Gianny

>
> Thoughts?
>
> thanks
> david jencks