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

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/tran... > [3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... > [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(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 09/29/2009 04:55 PM, Manik Surtani wrote: > </snip> > > 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? Hmmmm, not sure I understand what you mean by declarative configurations here. I'd imagine AS, apart from being able to provide it's own Transport programatically, it could do do something like this in the Infinispan configurations running on AS: <transport transportClass="org.jboss.as.infinispan.JGroupsTransport" ... And within that implementation, lookup the JGroups transport in AS and return what the Transport interface mandates. The above example is what I understand by declarative. > > Cheers > Manik > > [1] https://jira.jboss.org/jira/browse/ISPN-185 > [2] http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/remoting/tran... > [3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... > [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(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

Can't we use an interface JGroupsChannelLookup { JChannel lookupChannel(); } This can be specified as a parameter to the trasport <property name="txLookup" value="org.xyz.MySpecificLookup"/> we are using 2 lookups already (TM, MBeanServerLookup) and this would be consistent with the code base. I would stick with the lookup within JGroupsTransport and not within the TransportLookup, as this seems rather particular.

On Sep 29, 2009, at 5:55 PM, 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/tran... > [3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... > [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(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 30 Sep 2009, at 13:23, Galder Zamarreno wrote: > > > On 09/30/2009 01:42 PM, Mircea Markus wrote: >> Can't we use an >> interface JGroupsChannelLookup { >> JChannel lookupChannel(); >> } >> This can be specified as a parameter to the trasport >> <property name="txLookup" value="org.xyz.MySpecificLookup"/> >> >> we are using 2 lookups already (TM, MBeanServerLookup) and this >> would >> be consistent with the code base. >> I would stick with the lookup within JGroupsTransport and not within >> the TransportLookup, as this seems rather particular. > > +1. > > It's something like this what I had in mind with my previous email > but > forgot of how complex JGroupsTransport and that it does much more > than > only create the JChannel. Makes sense. Brian, thoughts? Does this work for you? Cheers Manik -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev