Does the fact that JGroups uses LGPL at the moment (they plan to switch to APL 'soon') prevent it from being used in Sling?
Cheers, Stefan On 7/3/13 3:05 PM, "Carsten Ziegeler" <[email protected]> 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 <[email protected]> > >> 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 >[email protected]
