Thanks Gianny. More below...
On Jan 16, 2008, at 3:42 PM, Gianny Damour wrote:
> On 17/01/2008, at 1:30 AM, Kevan Miller wrote:
>
>>
>> On Jan 16, 2008, at 7:48 AM, gdamour@apache.org wrote:
>>
>>> Author: gdamour
>>> Date: Wed Jan 16 04:48:37 2008
>>> New Revision: 612439
>>>
>>> URL: http://svn.apache.org/viewvc?rev=612439&view=rev
>>> Log:
>>> Move farm related classes to new sub-project geronimo-farm. Add a
>>> new
>>> configuration "farming" and move farming related GBeans from the
>>> clustering
>>> config. to this new one. Also, by default this configuration is
>>> not started.
>>
>> Cool. Gianny, can you give us a bit of status about where you are
>> with this? Looks like you're laying some groundwork for OpenEJB
>> dependencies...
> Hi,
>
> David J. proposed a while back two clustering code/module
> rearrangements he was keen to have implemented before 2.1. With this
> commit, both of these rearrangements are now in.
Right. Although I haven't looked at the specifics, I think this split
is a really good one.
>
>
> I am now integration testing the OpenEJB clustering support and it
> appears I will need to do some minor adjustments. As part of the
> change, four sub-projects/dependencies are added: geronimo-openejb-
> clustering-wadi, geronimo-openejb-clustering-builder-wadi, openejb-
> clustering-wadi and openejb-clustering-builder-wadi. This structure
> mirrors the Jetty and Tomcat ones.
>
> I also think 2.1 is belated and should be cut as soon as possible. I
> will hold-on the OpenEJB commit till the creation of a 2.1 branch.
Cool. If this branch isn't for another week or two, is that going to
ok for you? I think we want to avoid creating branches/2.1 and then
merging a bunch of fit-and-finish fixes between the branch and trunk...
--kevan
>
>
> Thanks,
> Gianny
>
>>
>> Enhanced clustering support is really great to have. Want to
>> understand what additional dependencies this is going to require.
>>
>> I think we're overdue for a 2.1 release. We have polish and a
>> number of usability issues to work out in current trunk, prior to
>> this. However, worried about also pushing in a bunch of new
>> function is going to make this difficult...
>>
>> --kevan
>