On Tue, 2010-05-04 at 10:52 -0500, Brian Stansberry wrote:
Good stuff. :)
When can this appear in a release (i.e. a CR2) so Bela can plug it into
his M3 and play?
The changes discussed in this thread are already checked-in to trunk.
JFC, can we do a CR2 release this week? Admittedly, this would not
really be a proper release candidate - as we have a few more issues to
fix prior to GA...
Let's create a CR3 release in jira and reassign less urgent fixes
accordingly, so we can get CR2 out asap. Thoughts?
He's your best tester. It would be nice to get this
into AS trunk ASAP as well.
As soon as CR2 is out, I'll update the AS.
On 05/04/2010 10:16 AM, Paul Ferraro wrote:
> On Tue, 2010-05-04 at 09:57 +0200, Bela Ban wrote:
>> Paul Ferraro wrote:
>> TBH, I'm not a 100% sure what the code above does... is it adding a
>> lifecycle listener dynamically if mod_cluster is started after JBossWeb
>> ? Actually, I guess this will always be the case as you have a
>> dependency from mod-cluster to JBossWeb.
> In summary, if the jbossweb server exists that means the WebServer
> service was already started. If this is the case, then dynamically add
> the mod_cluster lifecycle listener, and trigger the init and start
> events manually (since those events were missed).
>>> This requires a small modification to the
>>> MicrocontainerIntegrationLifecycleListener, which will need to delegate
>>> equals(Object) to its non-null delegate listener if the argument is a
>>> LifecycleListener, but not an instanceof MCILL.
>>> So, this essentially does what you described. There are couple other
>>> 1. We no longer need to define a<Listener/> in server.xml (closes
>>> MODCLUSTER-20 !!!).
>> Because you're adding the listener dynamically, a la MODCLUSTER-20, right ?
>> Wow, that would be great !
>>> 2. We no longer rely on the finicky
>>> MicrocontainerIntegrationLifecycleListener, which requires (so to avoid
>>> a call to JBossWebMicrocontainerBeanLocator.getInstalledBean(...) on
>>> every lifecycle event) that the delegate listener is deployed prior to
>>> the start() of the WebServer service.
>>> 3. There is no longer any manual step to enable mod_cluster (e.g.
>>> uncommenting<depends>ModClusterListener</depends>) - the
>>> mod_cluster.sar is enough.
>> Cool ! So the mod-cluster SAR has a dependency on WebServer, and when
>> you dynamically deploy mod-cluster.sar, JBossWeb will already be
>> running, good !
>>> 4. It is still compatible with the mod_cluster configuration bundled
>>> with AS 6.0.0.M1-M3.
>>> 5. mod_cluster is now hot-deployable, independently of jbossweb. The
>>> addition of a corresponding stop() that removes the lifecycle listener
>>> will allow mod_cluster to be hot-undeployable.
>> Great !
> Yes - now mod_cluster can finally behave like a normal jboss service...
>> Excellent ! I like this a lot, because it simplifies things a lot and
>> reduces the amount of configuration to be done.
>> So when this is done, what will the configuration steps be (on the JBoss
>> AS side) ?
>> 1. Add a jvmRoute to server.xml [optional, as jvmRoute is generated
>> if absent]
> The default JvmRouteFactory allows system property override as well, via
>> 2. mod-cluster.sar:
>> 1. Set the proxy list (jboss.mod_cluster.proxyList) [optional
>> if IP multicasting works, as advertise is enabled by default]
> Advertise is not enabled by default - in order to minimize jboss's
> default port footprint. Advertise can be enabled via a system property.
> So, in summary, the servers just need to be started with either:
>> 2. Set the domain [optional if we use a system prop, or the
>> default domain]
>> 3. Use HAModClusterService instead of ModClusterService: for
>> the mod-cluster.sar located in 'all', can we make this the
>> default ?
> I alluded to this earlier when I mentioned splitting the
> ModClusterListener bean into a separate conf file and creating 2
> versions of it. One using HAModClusterService for use in the all
> profile, the other using ModClusterService for use in the default
> mod_cluster-dev mailing list