[infinispan-dev] ISPN-185: Injecting a running JGroups channel into Infinispan

[Manik Surtani]

On 29 Sep 2009, at 18:22, Vladimir Blagojevic wrote:

> Can't you add Channel parameter to Transport#inject and register  
> running
> JGroups channel with component registry?

That would require exposing the ComponentRegistry to client code (to  
allow for registering the Channel in the CR, _before_ the CacheManager  
is constructed).  The best way for the latter would still be to pass  
in a Channel to the DefaultCacheManager ctor though, since this is  
where a ComponentRegistry is created (and maintained).

The thing is that the CR is not meant to be a generic container, like  
JBoss MC.  As such, construction and bootstrap of the CR is non- 
trivial and closely tied to the construction and bootstrap of the  
DefaultCacheManager (built this way to remove bloat and for  
performance).  So we can't even expect users to create and pre- 
populate a CR and pass that in to the DefaultCacheManager's ctor.

- Manik

>
> On 09-09-29 10:55 AM, Manik Surtani wrote:
>> Regarding ISPN-185 [1] (Need to provide a mechanism in which a  
>> JGroups
>> channel can be passed in), I'd like to discuss a few solutions.  I
>> believe this directly affects the way JBoss AS will use Infinispan,  
>> so
>> it would be good to hear from JBoss AS folk on this subject.  :)
>>
>> Transport [2] is an interface that wraps up the JGroups Channel  
>> (among
>> other things), and the default (only?) implementation so far is the
>> JGroupsTransport [3].  Now one thing we can do to support channel
>> injection is to actually support Transport injection.  This way a
>> Transport can be constructed (simple constructor), the JGroups  
>> channel
>> set, and the transport passed in to a GlobalConfiguration instance
>> (setter TBD), which is then in turn passed to a DefaultCacheManager
>> constructor [4].
>>
>> The problem with this approach though, is that it will only work for
>> programmatic configurations.  To support declarative configurations  
>> as
>> well, we'd need to override the relevant DefaultCacheManager
>> constructors [5] [6] [7] [8] to accept a Transport as well.  But this
>> pollutes the CacheManager API, in my opinion.
>>
>> So, how important is it that a running channel is used to override
>> something defined in XML?
>>
>> Cheers
>> Manik
>>
>> [1] https://jira.jboss.org/jira/browse/ISPN-185
>> [2] http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/remoting/transport/Transport.html
>> [3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java?r=883
>> [4] http://bit.ly/3roPkl
>> [5] http://bit.ly/vDtwa
>> [6] http://bit.ly/2FhsUn
>> [7] http://bit.ly/7YC8d
>> [8] http://bit.ly/2rgtyP
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org