or we just use Hazelcast.. :) On 7/5/13 12:44 PM, "Robert Munteanu" <romb...@apache.org> wrote:
>On Fri, Jul 5, 2013 at 1:29 PM, Carsten Ziegeler <cziege...@apache.org> >wrote: >> Yep, it's a blocker - so we should use something else or wait and >>increase >> the pressure to make them switch :) > > >I found out today that the switch is complete in the master branch >[1], so we can start using it right now if we want to. > >However, there still isn't an official release. According to the >project lead, there isn't a definite date for JGroups 3.4 ( first >APL-licensed version), but it should be before Infinispan 6.0 is out. > >Robert > > >[1]: https://issues.jboss.org/browse/JGRP-1643 > >> >> >> Carsten >> >> >> 2013/7/5 Robert Munteanu <rob...@lmn.ro> >> >>> On Fri, Jul 5, 2013 at 12:18 PM, Stefan Egli <e...@adobe.com> wrote: >>> > Does the fact that JGroups uses LGPL at the moment (they plan to >>>switch >>> to >>> > APL 'soon') prevent it from being used in Sling? >>> >>> AFAIK LGPL is a blocker, see [1] >>> >>> Robert >>> >>> [1]: http://www.apache.org/legal/resolved.html#category-x >>> >>> > >>> > Cheers, >>> > Stefan >>> > >>> > On 7/3/13 3:05 PM, "Carsten Ziegeler" <cziege...@apache.org> wrote: >>> > >>> >>Thanks for taking this up, Stefan. >>> >> >>> >>I think we should also try to close down the first version of the >>> >>discovery >>> >>api and release this, so other parts of our code can really rely on >>>this >>> >>api. >>> >> >>> >>Apart from that, I don't have a strong preference, although it would >>>be >>> >>nice to just use Apache stuff :) >>> >> >>> >>Regards >>> >>Carsten >>> >> >>> >> >>> >>2013/7/1 Stefan Egli <e...@adobe.com> >>> >> >>> >>> Hi, >>> >>> >>> >>> I've created SLING-2939 [0] to track an additional, 3rd party based >>> >>> implementation of the discovery.api. The idea is to complement the >>> >>> discovery.impl (which is ootb, entirely sling-based) with a more >>> mature, >>> >>> specialized, scalable implementation based on a clustering library. >>> I've >>> >>> summarized some pros/cons of possible candidates, including some >>> already >>> >>> received feedback in the ticket. I would appreciated further >>>feedback! >>> >>> >>> >>> It looks like Zookeeper/Curator would be a very good fit, >>> >>>requirement-wise >>> >>> but there was also an argument for using JGroups (or something >>>like >>> >>> Infinispan ontop of it), although that's LGPL at the moment. >>> >>> >>> >>> At the same time, it might be a good time to discuss if there's any >>> need >>> >>> for api changes, like 'topology-wide leader' or >>> >>> 'grouping/spliting/organizing topologies'. In discussions >>>surrounding >>> >>> topologies, other more consensus-like topics came up (things which >>> >>> zookeeper/curator would cover nicely). The question here is though >>>if >>> >>>that >>> >>> fits into the discovery api itself or if that's not something >>> completely >>> >>> different and out-of-scope of discovery. >>> >>> >>> >>> Thanks, >>> >>> Cheers, >>> >>> Stefan >>> >>> -- >>> >>> [0] - https://issues.apache.org/jira/browse/SLING-2939 >>> >>> >>> >>> >>> >> >>> >> >>> >>-- >>> >>Carsten Ziegeler >>> >>cziege...@apache.org >>> > >>> >>> >>> >>> -- >>> Sent from my (old) computer >>> >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org
