On Aug 4, 2011, at 4:22 PM, Sanne Grinovero wrote: > 2011/8/4 Galder Zamarreño <gal...@redhat.com>: >> >> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote: >> >>> 2011/8/4 Dan Berindei <dan.berin...@gmail.com>: >>>> </snip> >>> >>> Are you proposing a temporary API to make things work before ISPN-658 >>> is solved? I don't like the Future approach, it's still unclear that I >>> have to send all requests before blocking on any get. >>> I'd make a >>> >>> void startCaches(String... names); >>> >>> which implicitly includes the default cache too, and you throw an >>> exception if getCache() is used on an unstarted cache, and >>> unfortunately you should also throw an exception if startCaches() is >>> invoked more than once. >> >> We talk about this option too as indicated in >> https://gist.github.com/1124740, but I personally don't like it at this >> stage, since that'd be changing the programming model. People are expecting >> start caches with getCache(). It's been like that since 4.0 so what you're >> suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your >> suggestion would be worth considering for 6.x. > > agreed, as discussed with Dan we won't throw exceptions but log a > warning to recommend people use the startCaches(). > > Dan I still think the #startCaches method should at least log a > warning if it's invoked more than once: it's very useful to be aware > of the ISPN-658 as early as possible in the application design, and > this is a good chance for us to detect the unsupported usage pattern. > I think these two warnings combined can save a lot of time and stress, > and won't affect any body who is doing it correctly already.
Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about? > > +1 for Galder's fluent idea :) > > Cheers, > Sanne > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev