Ok, makes sense. Igor
On Tue, Jan 17, 2017 at 3:25 PM, Valentin Kulichenko < [email protected]> wrote: > Igor, > > I'm not against existing functionality and definitely do not propose to > rip and replace it. However, while Spring is not required, it's used in > vast majority of cases to configure Ignite. > > Having said that, I think this an important usability improvement. Here is > the ticket: https://issues.apache.org/jira/browse/IGNITE-4555 > > -Val > > On Sun, Jan 15, 2017 at 7:40 PM, Igor Rudyak <[email protected]> wrote: > >> Hi Val, >> >> The main reason why Spring wasn't utilized, is to support >> Ignite-Cassandra integration without using Spring. As you know, Spring is >> not required component to run Ignite. Thus the main idea to avoid Spring >> was to provide Cassandra integration for Spring-less Ignite environments. >> >> Igor >> >> On Fri, Jan 13, 2017 at 11:37 AM, Valentin Kulichenko < >> [email protected]> wrote: >> >>> Hi Igor, >>> >>> Why did you choose to use a special format instead of going with Spring >>> in the first place? It seems to that this is what creating difficulties >>> here, because with Spring any of scenarios we mentioned is possible: >>> >>> - You can create a template in XML, load it using >>> Ignition.loadSpringBean() and modify in code. >>> - You can provide full configuration in the same file where Ignite >>> configuration is. >>> - You can configure everything in code if you don't like XML. >>> >>> Current approach seems to introduce too many limitations to be usable. >>> Do you have any objections against making KeyValuePersistenceSettings class >>> Spring compatible? If not, I will create a ticket. Or maybe you have other >>> suggestions on how to improve flexibility here? >>> >>> -Val >>> >>> On Thu, Jan 12, 2017 at 6:09 PM, Igor Rudyak <[email protected]> wrote: >>> >>>> Good question. The main case for this getters/setters API is when you >>>> are going to dynamically create Cassandra persistence configuration for you >>>> cache. >>>> >>>> As I see it, in most cases developers will create kind of xml >>>> persistent descriptor template, which will be used to generate final >>>> persistence descriptor for particular cache or just reuse already existing >>>> persistence descriptor. In case you want to generate persistence descritor >>>> dynamically from scratch I don't see much difference from doing it using >>>> getters/setters API or generating XML document - in both cases it will be >>>> lot's of XML API or Persistence Descriptor API calls. >>>> >>>> Any thoughts? >>>> >>>> >>>> On Jan 12, 2017 3:36 PM, "Valentin Kulichenko" < >>>> [email protected]> wrote: >>>> >>>>> Hi Igor, >>>>> >>>>> I just noticed that KeyValuePersistenceSettings class required to >>>>> configure Cassandra store can be created only based on XML file of a >>>>> special format. >>>>> >>>>> If so, this looks like a pretty serious limitation. First of all, when >>>>> configuring such cache, user has to know both Spring configuration format >>>>> and this specific format for persistence. In other words, persistence >>>>> configuration seems to be weirdly separated from all other configurations >>>>> in a separate file with a different format. >>>>> >>>>> But most importantly, what if user wants to create a cache dynamically >>>>> and doesn't know configuration in advance? How are they supposed to create >>>>> this special XML in this case? >>>>> >>>>> Is my understanding correct? If so, I think we should add standard >>>>> getters and setters to KeyValuePersistenceSettings. This will make it >>>>> compatible with Spring and will allow to create it dynamically in code. >>>>> >>>>> Agree? >>>>> >>>>> -Val >>>>> >>>> >>> >> >
