Michael, Thanks, for verifying.
I've tried extending ClientConfiguration but couldn't get the > getters/setters working with ConfigurationBuilder. Instead they are just > placed into wrapper classes. Have a look at how Hazelcast implemented the default configuration for its thin client by extending ClientConfig class of Hazelcast core: https://github.com/micronaut-projects/micronaut-cache/blob/master/cache-hazelcast/src/main/java/io/micronaut/cache/hazelcast/HazelcastClientConfiguration.java Some observations. After extending ClientConfig, their Micronaut's HazelcastClientConfiguration exposes the following configuration parameteres: - Some fields of primitive types that belong to the parent ClientConfig class. They do this by adding this - *includes = {"properties", "instanceName", "labels", "userContext", "clusterName"}* - ClientNetworkConfig, ConnectionRetryConfig, SocketOptions properties (that exist in the parent ClientConfig class) can not be inherited as above. Thus, they define those with @ConfigurationBuilder manually. As a result, their implementation is simple and compact, and here is a final list of configuration properties: https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#io.micronaut.cache.hazelcast.HazelcastClientConfiguration Could you check if we can follow a similar approach? Let's start with the thin client. It's much simpler. > yea, will need to > setup a way for a user to provide their own bean because there is no way a > full configuration could be covered but I haven't quite worked that out > yet. That will be outstanding and fit well the design. Let me know if you need me to help to figure out how to do that with Micronaut. - Denis On Fri, Aug 21, 2020 at 5:52 PM Michael Pollind <mpoll...@gmail.com> wrote: > Dennis, > > This is what I came up with with some of the suggestions: > > https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java > and > > https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultCacheConfiguration.java > > test cases: > > https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/test/groovy/io/micronaut/ignite/IgniteConfigurationSpec.groovy > > I've tried extending ClientConfiguration but couldn't get the > getters/setters working with ConfigurationBuilder. Instead they are just > placed into wrapper classes. Anyways, I don't think ConfigurationProperty > is supposed to work this way. Also note the table in the documentation is > generated and without a way to exclude things I don't think this will work > cleanly. The other thing I wanted to do was nest @EachProperty in a single > @ConfigurationProperties but that doesn't work with how stuff gets resolved > (https://github.com/micronaut-projects/micronaut-core/issues/3938). so the > cachConfiguration is in another class. This is kind of a first working > example so this will need to be adjusted quite a bit. yea, will need to > setup a way for a user to provide their own bean because there is no way a > full configuration could be covered but I haven't quite worked that out > yet. > > If this is ok then I can do another pass on the confluence. > > On Fri, Aug 21, 2020 at 1:55 PM Denis Magda <dma...@apache.org> wrote: > > > Michael, > > > > Finally, I figured out Micronaut configuration specificities. What > confused > > me before, is that even though the beans configuration in Micronaut looks > > quite similar to the Spring Boot approach, the former automates a lot > with > > the help of reflection in runtime. That's how our default Spring Boot > > configuration looks > > < > > > https://github.com/apache/ignite-extensions/blob/master/modules/spring-boot-thin-client-autoconfigure-ext/src/main/java/org/apache/ignite/springframework/boot/autoconfigure/IgniteClientConfigurer.java > > > > > like. And that's enough to let the users define any possible property of > an > > IgniteConfiguration instance as per this example > > < > > > https://apacheignite-mix.readme.io/docs/spring-boot#set-ignite-up-via-spring-boot-configuration > > >. > > The upside of the reflection. > > > > Anyway, let's go back to our world. That's what I would suggest. > > > > *Ignite Thin Client* > > > > > > - Let's create DefaultThinClientConfiguration that *extends* Ignite's > > ClientConfiguration > > < > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java > > >. > > Once done, it will be possible to configure most of > ClientConfiguration > > settings which are primitive types. (guess that's how you were doing > > that > > before I joined the review) > > - Some fields of the ClientConfiguration class are of custom > > non-primitive types and should be added into the > > DefaultThinClientConfiguration explicitly via the > @ConfigurationBuilder > > annotation. Those fields are *sslType, sslProtocol, > > sslCtxFactory, txCfg*. > > > > Apart from the DefaultThinClientConfiguration, can we support another > > configuration approach when a ClientConfiguration bean is created > > programmatically in the source code and the integration uses that bean to > > initialize an instance of the thin client (instead of > > using DefaultThinClientConfiguration that requires to set the properties > > via YAML,etc.). For instance, that's how the ClientConfiguration bean is > > created programmatically in Spring Boot > > < > > > https://apacheignite-mix.readme.io/docs/spring-boot#set-thin-client-up-programmatically > > >and > > our integration uses it to initialize an Ignite object. > > > > *Ignite Node (server or thick client)* > > > > Obviously, this one is trickier due to the numerous configuration > > parameters of the IgniteConfiguration class > > < > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/IgniteConfiguration.java > > > > > . > > > > So, as you suggested before, we need to select the most frequently used > > configuration parameters and add them to the DefaultIgniteConfiguration > > with @ConfigurationBuilder annotation. However, it seems reasonable if > > DefaultIgniteConfiguration will extend Ignite's IgniteConfiguration (so > > that we don't need to list parameters of primitive types). Based on my > > experience, I would add the following settings of custom non-primitive > > types: > > > > - TcpDiscoverySpi > > < > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.java > > > > > with > > all its fields of primitive types (this should be done easily, right, > > without copy-paste?) and its ipFinder field. In the beginning, I would > > only > > support setting TcpDiscoveryVmIpFinder > > < > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/vm/TcpDiscoveryVmIpFinder.java > > > > > and > > KubernetesIpFinder > > < > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/kubernetes/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/kubernetes/TcpDiscoveryKubernetesIpFinder.java > > >via > > the DefaultIgniteConfiguration. > > - DataStorageConfiguration > > < > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/configuration/DataStorageConfiguration.java > > > > > including > > its DataStorageConfiguration.dataRegions property. > > - TcpCommunicationSpi > > < > > > https://github.com/apache/ignite/blob/f4b30f7f1e736845ffa8eaf2d8aa171700a928eb/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java > > > > > with > > its fields of primitive types. Again, here is I'm assuming that we can > > do > > this avoiding copy-pasting. Either through @ConfigurationBuilder > > (include) > > or inheritence. > > > > If the user wants to configure any settings unsupported by > > DefaultIgniteConfiguration then, there should be a way to create an > > IgniteConfiguration bean programmatically and use it to initialize an > > Ignite instance (instead of DefaultIgniteConfiguration). > > > > What's your thinking? Let me know if I'm still missing something. > > - > > Denis > > > > > > On Wed, Aug 19, 2020 at 8:49 PM Saikat Maitra <saikat.mai...@gmail.com> > > wrote: > > > > > Hi Michael, Denis > > > > > > I was looking into tiering options for ehcache[1] and network options > for > > > Hazelcast[2] and I am thinking we can implement something similar to > > > configure CommunicationSpi > > > > > > > > > [1] > > > > > > > > > https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#ehcache > > > [2] > > > > > > > > > https://micronaut-projects.github.io/micronaut-cache/snapshot/guide/#hazelcast > > > > > > Let me know what you think. > > > > > > Regards, > > > Saikat > > > > > > > > > > > > > > > On Wed, Aug 19, 2020 at 7:09 PM Michael Pollind <mpoll...@gmail.com> > > > wrote: > > > > > > > A lot of this was just figured out through experimentation. You can > ask > > > > questions in the micronaut gitter: > > > > https://gitter.im/micronautfw/questions > > > > . Micronaut documentation is pretty comprehensive: > > > > https://docs.micronaut.io/latest/guide/index.html. look for > > EachProperty > > > > and ConfigurationProperty. you can also hunt through the current > > existing > > > > micronaut modules and find how those configuration items are setup. > > There > > > > is also the unit test cases in micronaut-core which have been pretty > > > > helpful in the past in working out how some of these annotations work > > in > > > > practice. > > > > > > > > On Wed, Aug 19, 2020 at 4:50 PM Denis Magda <dma...@apache.org> > wrote: > > > > > > > > > Michael, > > > > > > > > > > Alright, then the question on the possible quantity of Ignite > > instances > > > > is > > > > > settled - the integration will allow to auto-configure a single > > > instance > > > > > only. > > > > > > > > > > Give me a couple of days to look into the configuration matters of > > > > > DefaultIgniteConfiguration and see what I can suggest. Could you > > > > recommend > > > > > any materials (or sources) that on Micronaut configuration > specifies > > > > > (through YAML and programmatically via source code)? > > > > > > > > > > Denis > > > > > > > > > > On Wednesday, August 19, 2020, Michael Pollind <mpoll...@gmail.com > > > > > > wrote: > > > > > > > > > > > I don't think micronaut will be able to infer the > communicationSpi, > > > so > > > > > you > > > > > > need to define it separately as follows: > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > > > rework-1/ignite-core/src/main/java/io/micronaut/ignite/configuration/ > > > > > > DefaultIgniteConfiguration.java#L40-L43. > > > > > > With this setup the configuration should look pretty much like > the > > > > > > spring-boot sample you showed me: > > > > > > https://apacheignite-mix.readme.io/docs/spring-boot# > > > > > > set-ignite-up-via-spring-boot-configuration. > > > > > > I agree it should make the configuration easier with just > allowing > > a > > > > > single > > > > > > instance and it matches up well with spring-boot configuration: > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/ > > > > > > context/annotation/Requires.html. > > > > > > Since its mostly a niche usecase then having that as the default > > use > > > > case > > > > > > seems pretty ideal to me. the definition will work as follows: > > > > > > > > > > > > ignite: > > > > > > enable true > > > > > > ignite-instance-name: name > > > > > > communication-spi: > > > > > > local-port: 5555 > > > > > > data-storage-configuration: > > > > > > ... > > > > > > cache-configurations: > > > > > > - name: accounts > > > > > > queryEntities: > > > > > > - tableName: NAME > > > > > > ... > > > > > > - ... > > > > > > ignite-thin: > > > > > > enable: false > > > > > > instance-name: name > > > > > > > > > > > > > > > > > > Micronaut has some mechanism to enforce the presence of something > > > that > > > > > > should suffice for this usecase: > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/ > > > > > > context/annotation/Requires.html > > > > > > > > > > > > > > > > > > On Wed, Aug 19, 2020 at 2:45 PM Denis Magda <dma...@apache.org> > > > wrote: > > > > > > > > > > > > > Michael, > > > > > > > > > > > > > > > > > > > > > > The current way I have it setup is the primary bean is used > by > > > > > default > > > > > > so > > > > > > > > you won't be able to use micronaut-cache with anything but > the > > > > > default > > > > > > > > bean. I guess one can override the other if the configuration > > is > > > > > > present. > > > > > > > > > > > > > > > > > > > > > The more I'm thinking the more I'm convinced that we shouldn't > > > bother > > > > > > about > > > > > > > the auto-configuration of several Ignite instances. As I said > > > before, > > > > > > > that's an occasional use case. Furthermore, Micronout is > designed > > > for > > > > > > > micro-services and serverless functions and I can hardly think > > of a > > > > use > > > > > > > case when a micro-service or function would need to boot up > > several > > > > > > Ignite > > > > > > > clients. What if we let to auto-configure a single Ignite > > instance > > > > per > > > > > > > application process? What's your view on this? It will > > > significantly > > > > > > > simplify the design and implementation of integration. If > anybody > > > > needs > > > > > > > several Ignite instances, then he can instantiate them > manually. > > > > > > > > > > > > > > By default the > > > > > > > > thick client instance will replace the thin-client > DynamicCache > > > if > > > > > that > > > > > > > > would be ok? > > > > > > > > > > > > > > > > > > > > > If you agree on my proposal above, then I would simply disallow > > > > > > > auto-starting more than one Ignite instance (let it be a thick > or > > > > thin > > > > > > > client). For example, if a thick client is already started, > then > > > > throw > > > > > an > > > > > > > exception on an attempt to initialize a thin client (and vice > > > versa). > > > > > As > > > > > > > for thick vs. thin client usage in relation to Micronaut, I > would > > > > > > recommend > > > > > > > using the thin client if Micronaut is deployed in a serverless > > > > function > > > > > > > (the thin client connects to the cluster faster), while for > > > > > > micro-services > > > > > > > you can use both types of clients. > > > > > > > > > > > > > > The main reason why I was using the spring bean definition was > > > mainly > > > > > for > > > > > > > > convenience and I'm not sure what fields are the most > relevant. > > > > > > > > > > > > > > > > > > > > > Ok, seems that I'm missing some important point about > Micronaut. > > > Let > > > > me > > > > > > > double-check the following with you. > > > > > > > > > > > > > > Assume these are the only fields of the > > DefaultIgniteConfiguration: > > > > > > > > > > > > > > private final String name; > > > > > > > > > > > > > > @ConfigurationBuilder() > > > > > > > private IgniteConfiguration igniteConfiguration = new > > > > > > > IgniteConfiguration(); > > > > > > > > > > > > > > > > > > > > > Will I be able to set up the communicationSpi bean below > without > > > > having > > > > > > it > > > > > > > as a field of the DefaultIgniteConfiguration? Are you getting a > > > > > > > NullPointerException? > > > > > > > > > > > > > > ignite: > > > > > > > name: some_name > > > > > > > igniteConfiguration: > > > > > > > communicationSpi: > > > > > > > {redefining some fields of the SPI} > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 19, 2020 at 12:17 AM Michael Pollind < > > > mpoll...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Here is the initial setup that I quickly threw together along > > > with > > > > > some > > > > > > > > example test cases. I feel like this might get a little > > > complicated > > > > > > but I > > > > > > > > think it's doable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > > > rework-1/ignite-core/src/main/java/io/micronaut/ignite/configuration/ > > > > > > DefaultIgniteConfiguration.java > > > > > > > > along with some relevant test: > > > > > > > > > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > rework-1/ignite-core/src/test/groovy/io/micronaut/ignite/ > > > > > > IgniteConfigurationSpec.groovy#L55-L73 > > > > > > > > > > > > > > > > On Tue, Aug 18, 2020 at 11:49 PM Michael Pollind < > > > > mpoll...@gmail.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> > > > > > > > >> > > > > > > > >> The main reason why I was using the spring bean definition > was > > > > > mainly > > > > > > > for > > > > > > > >> convenience and I'm not sure what fields are the most > > relevant. > > > > Will > > > > > > > have > > > > > > > >> to be kind of specific since the configuration might get a > > > little > > > > > > > >> complicated. The other thing you can do is use > > > > > > > >> > > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/core/ > > > > > > convert/format/MapFormat.html > > > > > > > >> which will just map fields and values and you can pass that > to > > > > > > somewhere > > > > > > > >> else to be manage it. > > > > > > > >> > > > > > > > >> so you will need to do something like this as follows: > > > > > > > >> > > > > > > > >> private final String name; > > > > > > > >> @ConfigurationBuilder() > > > > > > > >> private IgniteConfiguration igniteConfiguration = new > > > > > > > IgniteConfiguration(); > > > > > > > >> @ConfigurationBuilder(value = "communicationSpi") > > > > > > > >> private TcpCommunicationSpi communicationSpi = new > > > > > > > TcpCommunicationSpi(); > > > > > > > >> > > > > > > > >> [image: image.png] > > > > > > > >> > > > > > > > >> > > > > > > > >> On Tue, Aug 18, 2020 at 11:05 PM Michael Pollind < > > > > > mpoll...@gmail.com> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >>> Its whatever is setup by default when the object is > > declared. I > > > > > think > > > > > > > we > > > > > > > >>> will have to define multiple ConfigurationBuilders If i'm > not > > > > > > mistaken > > > > > > > for > > > > > > > >>> the IgniteConfiguration. you don't need to provide the > name > > > > since > > > > > > > that is > > > > > > > >>> provided by the key for each configuration under > > EachProperty. > > > > The > > > > > > > name is > > > > > > > >>> the qualified name that refers to that bean and also the > same > > > > > > > qualifier for > > > > > > > >>> the Ignite instance. For the most part will just use the > > > primary > > > > > bean > > > > > > > for > > > > > > > >>> most part. I think you can only have one cache instance > > active > > > > at a > > > > > > > time. > > > > > > > >>> The current way I have it setup is the primary bean is used > > by > > > > > > default > > > > > > > so > > > > > > > >>> you won't be able to use micronaut-cache with anything but > > the > > > > > > default > > > > > > > >>> bean. I guess one can override the other if the > configuration > > > is > > > > > > > present. > > > > > > > >>> One problem I see is micronaut-cache. We can only use one > > > > instance > > > > > of > > > > > > > >>> DynamicCache but I need to verify how that works again. By > > > > default > > > > > > the > > > > > > > >>> thick client instance will replace the thin-client > > DynamicCache > > > > if > > > > > > that > > > > > > > >>> would be ok? > > > > > > > >>> > > > > > > > >>> ignite: > > > > > > > >>> thick-clients: > > > > > > > >>> default: <--- primary bean > > > > > > > >>> ... > > > > > > > >>> second-bean: > > > > > > > >>> ... > > > > > > > >>> thin-clients: > > > > > > > >>> default: <--- primary bean > > > > > > > >>> ... > > > > > > > >>> second-bean: > > > > > > > >>> .... > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > https://docs.micronaut.io/latest/api/io/micronaut/ > > > > > > context/annotation/Requires.html > > > > > > > >>> > > > > > > > >>> On Tue, Aug 18, 2020 at 10:13 PM Denis Magda < > > > dma...@apache.org> > > > > > > > wrote: > > > > > > > >>> > > > > > > > >>>> > > > > > > > > >>>> > oh, so we probably don't need to work with multiple > > > instances. > > > > > > This > > > > > > > >>>> is what > > > > > > > >>>> > I have in the current master branch. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> In most cases, people start a single instance of a thick > or > > > thin > > > > > > > client > > > > > > > >>>> per > > > > > > > >>>> application. The clients are multi-threaded and can > utilize > > > all > > > > > the > > > > > > > CPUs > > > > > > > >>>> effectively. However, it's not harmful to have the ability > > to > > > > > > > configure > > > > > > > >>>> several clients per application. As far as I understand, > > > > Micronaut > > > > > > > >>>> distinguishes clients per the > > "IgniteClientConfiguration.name" > > > > > > > property, > > > > > > > >>>> right? > > > > > > > >>>> > > > > > > > >>>> So what defaults are set for IgniteConfiguration? > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> Does it matter to Micronaut what those defaults are? By > > > looking > > > > at > > > > > > the > > > > > > > >>>> IgniteThinClientConfiguration > > > > > > > >>>> < > > > > > > > >>>> > > > > > > > https://micronaut-projects.github.io/micronaut-ignite/ > > > > > > snapshot/api/io/micronaut/ignite/configuration/ > > > > > > IgniteThinClientConfiguration.html > > > > > > > >>>> >, > > > > > > > >>>> that defines > > > org.apache.ignite.configuration.ClientConfiguration > > > > > > > >>>> property > > > > > > > >>>> (under the name of "configuration"), I see that Micronaut > > > could > > > > > > > >>>> introspect > > > > > > > >>>> all the fields of the ClientConfiguration and prepared > these > > > > > > > properties > > > > > > > >>>> table > > > > > > > >>>> < > > > > > > > >>>> > > > > > > > https://micronaut-projects.github.io/micronaut-ignite/ > > > > > > snapshot/guide/#io.micronaut.ignite.configuration. > > > > > > IgniteThinClientConfiguration > > > > > > > >>>> >. > > > > > > > >>>> For me, it means that whenever I am configuring the thin > > > client > > > > > in a > > > > > > > >>>> YAML > > > > > > > >>>> file, Micronaut will create an instance of the > > > > ClientConfiguration > > > > > > > >>>> (Ignite > > > > > > > >>>> sets the defaults), and then I can override some settings > > such > > > > as > > > > > > > >>>> "addresses" or "enablePartitionAwareness". Does this sound > > > > > accurate > > > > > > > >>>> concerning Micronaut? > > > > > > > >>>> > > > > > > > >>>> Jumping back to the IgniteConfiguration, I would just swap > > the > > > > > > "path" > > > > > > > >>>> that > > > > > > > >>>> is the String with the "config" that is > IgniteConfiguration. > > > > Then > > > > > > let > > > > > > > >>>> Ignite take care of the IgniteConfiguration defaults and > > > allow a > > > > > > > >>>> developer > > > > > > > >>>> to override some defaults (such as discoverySPI.ipFinder > or > > > > memory > > > > > > > >>>> settings). Just in case, you can find IgniteConfiguration > > > > defaults > > > > > > > here > > > > > > > >>>> < > > > > > > > >>>> > > > > > > > https://github.com/apache/ignite/blob/master/modules/ > > > > > > core/src/main/java/org/apache/ignite/configuration/ > > > > > > IgniteConfiguration.java > > > > > > > >>>> > > > > > > > > >>>> . > > > > > > > >>>> > > > > > > > >>>> - > > > > > > > >>>> Denis > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> On Tue, Aug 18, 2020 at 8:59 PM Michael Pollind < > > > > > mpoll...@gmail.com > > > > > > > > > > > > > > >>>> wrote: > > > > > > > >>>> > > > > > > > >>>> > oh, so we probably don't need to work with multiple > > > instances. > > > > > > This > > > > > > > >>>> is what > > > > > > > >>>> > I have in the current master branch. I believe I was > > > > originally > > > > > > > >>>> trying to > > > > > > > >>>> > set-up the configuration with the default ignite > instance > > > but > > > > > > found > > > > > > > I > > > > > > > >>>> > couldn't cover enough of the configuration. So what > > defaults > > > > are > > > > > > set > > > > > > > >>>> for > > > > > > > >>>> > IgniteConfiguration? some of those factory items can't > be > > > > > covered > > > > > > > >>>> with how > > > > > > > >>>> > micronaut sets up configurations. @ConfigurationProperty > > can > > > > > only > > > > > > be > > > > > > > >>>> > defined on a known factory, there are ways to have > > multiple > > > > > > > factories > > > > > > > >>>> and > > > > > > > >>>> > label them optional but that easily gets overwhelming. > In > > > > this > > > > > > > >>>> situation > > > > > > > >>>> > providing your own bean would probably be more ideal in > > this > > > > > > > >>>> situation when > > > > > > > >>>> > I think about it. I was worrying that I wouldn't be > able > > to > > > > > cover > > > > > > > >>>> enough > > > > > > > >>>> > of the configuration with > > > > > > > >>>> > > > > > > > > >>>> > ignite: enabled: true thin-clients: default: > > > > address: > > > > > > > - > > > > > > > >>>> > "127.0.0.1:10800" - "127.0.0.1:10801" > > > > > > > >>>> > > > > > > > > >>>> > thin-client-2: > > > > > > > >>>> > address: - "127.0.0.1:10800" - " > > > > 127.0.0.1:10801 > > > > > " > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > you can see it in the current snapshot documentation: > > > > > > > >>>> > > > > > > > > > > > > > https://micronaut-projects.github.io/micronaut-ignite/snapshot/guide/ > > > > > > > >>>> > > > > > > > > >>>> > On Tue, Aug 18, 2020 at 4:16 PM Denis Magda < > > > > dma...@apache.org> > > > > > > > >>>> wrote: > > > > > > > >>>> > > > > > > > > >>>> > > Michael, thanks for filling out the wiki page. > > > > > > > >>>> > > > > > > > > > >>>> > > I'm looking at the Auto-Configuration wiki section and > > the > > > > > > current > > > > > > > >>>> > version > > > > > > > >>>> > > of the io.micronaut.ignite.configuration. > > > > > > IgniteClientConfiguration > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-ignite/ > > > > > > > > > > > > blob/master/ignite-core/src/main/java/io/micronaut/ignite/configuration/ > > > > > > IgniteClientConfiguration.java > > > > > > > >>>> > > > > > > > > > > >>>> > > class, > > > > > > > >>>> > > and wonder if we can perform the following changes: > > > > > > > >>>> > > > > > > > > > >>>> > > 1. Rename the IgniteClientConfiguration to > > > > > > IgniteConfiguration > > > > > > > >>>> (or, to > > > > > > > >>>> > > avoid ambiguity, even to DefaultIgniteConfiguration > > as > > > > it's > > > > > > > done > > > > > > > >>>> for > > > > > > > >>>> > the > > > > > > > >>>> > > Mongo driver > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://micronaut-projects.github.io/micronaut-mongodb/ > > > > > > latest/api/io/micronaut/configuration/mongo/reactive/ > > > > > > DefaultMongoConfiguration.html > > > > > > > >>>> > > >). > > > > > > > >>>> > > The rationale for this change is that the > developers > > > > might > > > > > > need > > > > > > > >>>> to > > > > > > > >>>> > > start an embedded > > > > > > > >>>> > > Ignite server node > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://www.gridgain.com/docs/latest/installation-guide/ > > > > > > deployment-modes#embedded-deployment > > > > > > > >>>> > > >. > > > > > > > >>>> > > So, I would not limit the integration scope to the > > > Ignite > > > > > > > clients > > > > > > > >>>> > only. > > > > > > > >>>> > > 2. Presently, > > > > > > > >>>> > > > > > io.micronaut.ignite.configuration.IgniteClientConfiguration > > > > > > > >>>> > > supports two parameters - the "name" and "path". I > > > would > > > > > > > replace > > > > > > > >>>> the > > > > > > > >>>> > > "path" > > > > > > > >>>> > > parameter with the "config" one that instantiates > > > > > > > >>>> > > org.apache.ignite.IgniteConfiguration. If we do > that, > > > > then > > > > > > the > > > > > > > >>>> > > developers > > > > > > > >>>> > > will be able to set any property of the > > > > IgniteConfiguration > > > > > > > >>>> straight > > > > > > > >>>> > in > > > > > > > >>>> > > the > > > > > > > >>>> > > main YAML file. See how it's done for the Ignite > > Spring > > > > > Boot > > > > > > > >>>> > > Auto-Configuration > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://apacheignite-mix.readme.io/docs/spring-boot# > > > > > > set-ignite-up-via-spring-boot-configuration > > > > > > > >>>> > > >. > > > > > > > >>>> > > Guess, we can do the same with Micronaut. > > > > > > > >>>> > > 3. If the previous modification is feasible, then I > > > would > > > > > > > rework > > > > > > > >>>> the > > > > > > > >>>> > > Ignite thin client configuration similarly, taking > > our > > > > > Spring > > > > > > > >>>> Boot > > > > > > > >>>> > > integration for the thin client > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://apacheignite-mix.readme.io/docs/spring-boot# > > > > > > set-thin-client-up-via-spring-boot-configuration > > > > > > > >>>> > > > > > > > > > > >>>> > > as a reference. As I see, the current version of > > > > > > > >>>> > > IgniteThinClientConfiguration > > > > > > > >>>> > > < > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-ignite/ > > > > > > > > > > > > blob/master/ignite-core/src/main/java/io/micronaut/ignite/configuration/ > > > > > > IgniteThinClientConfiguration.java > > > > > > > >>>> > > > > > > > > > > >>>> > > already > > > > > > > >>>> > > adopts this approach. I would only rename > > > "configuration" > > > > > to > > > > > > > >>>> "config", > > > > > > > >>>> > > and > > > > > > > >>>> > > remove the "transaction" field since you can pass > the > > > > > > > >>>> transactional > > > > > > > >>>> > > settings via the YAML following the format below: > > > > > > > >>>> > > > > > > > > > >>>> > > ignite-thin-client: > > > > > > > >>>> > > name: > > > > > > > >>>> > > config: > > > > > > > >>>> > > addresses: <IP_addresses> > > > > > > > >>>> > > partitionAwarenessEnabled: true > > > > > > > >>>> > > transactionConfiguration: > > > > > > > >>>> > > defaultTxConcurrency:... > > > > > > > >>>> > > defaultTxTimeout > > > > > > > >>>> > > > > > > > > > >>>> > > - > > > > > > > >>>> > > Denis > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> > > On Mon, Aug 17, 2020 at 6:50 PM Michael Pollind < > > > > > > > mpoll...@gmail.com > > > > > > > >>>> > > > > > > > > >>>> > > wrote: > > > > > > > >>>> > > > > > > > > > >>>> > > > oh, that makes more sense. so those methods get > > wrapped > > > > > into a > > > > > > > >>>> > > > micronaut-aop intercept. Below I've listed the > > relevant > > > > > > sections > > > > > > > >>>> of > > > > > > > >>>> > code > > > > > > > >>>> > > > that would handle each annotation along with the > > methods > > > > > that > > > > > > > get > > > > > > > >>>> > called > > > > > > > >>>> > > > from the ignite branch I'm working from. Hopefully > > this > > > > > helps. > > > > > > > >>>> The key > > > > > > > >>>> > is > > > > > > > >>>> > > > specified from the CacheConfig annotation but this > can > > > be > > > > > > > changed > > > > > > > >>>> if > > > > > > > >>>> > > there > > > > > > > >>>> > > > is a better way to represent the key. By default it > > uses > > > > > this > > > > > > > >>>> > > > DefaultCacheKeyGenerator( > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/ > > > > > > master/cache-core/src/main/java/io/micronaut/cache/interceptor/ > > > > > > DefaultCacheKeyGenerator.java > > > > > > > >>>> > > > ). > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > I also finished up this document on sunday: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration > > > > > > > >>>> > > . > > > > > > > >>>> > > > Any suggestions with what I could expand on and how > > this > > > > > could > > > > > > > be > > > > > > > >>>> > > adjusted. > > > > > > > >>>> > > > > > > > > > > >>>> > > > Cacheable: > > > > > > > >>>> > > > > > > > > > > >>>> > > > For Cacheable it will run a get and issue a put if > the > > > > value > > > > > > is > > > > > > > >>>> not > > > > > > > >>>> > > present > > > > > > > >>>> > > > in the cache. > > > > > > > >>>> > > > > > > > > > > >>>> > > > -> micronaut-cache: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/ > > > > > > master/cache-core/src/main/java/io/micronaut/cache/ > > > > > > interceptor/CacheInterceptor.java#L163-L170 > > > > > > > >>>> > > > -> ignite-cache: > > > > > > > >>>> > > > get: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/ > > > > > > IgniteSyncCache.java#L60-L70 > > > > > > > >>>> > > > > > > > > > > >>>> > > > CachePut: > > > > > > > >>>> > > > > > > > > > > >>>> > > > For cache put it will invalidate if the return is > null > > > > else > > > > > it > > > > > > > >>>> will > > > > > > > >>>> > > issue a > > > > > > > >>>> > > > put. I think there might be a mistake in my code > > > because I > > > > > use > > > > > > > >>>> > > putIfAbsent > > > > > > > >>>> > > > for both cases. I need to investigate that closer > and > > > > write > > > > > > some > > > > > > > >>>> > > additional > > > > > > > >>>> > > > test cases to verify the behaviour. > > > > > > > >>>> > > > > > > > > > > >>>> > > > --> micronaut-cache: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/ > > > > > > master/cache-core/src/main/java/io/micronaut/cache/ > > > > > > interceptor/CacheInterceptor.java#L510-L525 > > > > > > > >>>> > > > -> ignite-cache: > > > > > > > >>>> > > > put: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/ > > > > > > IgniteSyncCache.java#L83-L88 > > > > > > > >>>> > > > invalidate: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/ > > > > > > IgniteSyncCache.java#L91-L95 > > > > > > > >>>> > > > > > > > > > > >>>> > > > CacheInvalidate: > > > > > > > >>>> > > > > > > > > > > >>>> > > > for cache invalidation it will just be removed by > the > > > key. > > > > > > > >>>> > > > > > > > > > > >>>> > > > --> micronaut-cache: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-cache/blob/ > > > > > > master/cache-core/src/main/java/io/micronaut/cache/ > > > > > > interceptor/CacheInterceptor.java#L590-L596 > > > > > > > >>>> > > > -> ignite-cache: > > > > > > > >>>> > > > invalidate: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/pollend/micronaut-ignite/blob/feature/ > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite/ > > > > > > IgniteSyncCache.java#L91-L95 > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > On Mon, Aug 17, 2020 at 5:23 PM Saikat Maitra < > > > > > > > >>>> saikat.mai...@gmail.com > > > > > > > >>>> > > > > > > > > > >>>> > > > wrote: > > > > > > > >>>> > > > > > > > > > > >>>> > > > > Hi Michael, > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > In the Example Cacheable Object you are using > > > @CachePut, > > > > > > > >>>> @Cacheable > > > > > > > >>>> > > > > annotations and @CacheInvalidate annotations and I > > was > > > > > > trying > > > > > > > to > > > > > > > >>>> > > > understand > > > > > > > >>>> > > > > when user use these annotation then what would be > > the > > > > > > > underlying > > > > > > > >>>> > Ignite > > > > > > > >>>> > > > > operation that will happen? and how those > operations > > > are > > > > > > > >>>> performed? > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > An example like when user call this below method > > then > > > > how > > > > > > the > > > > > > > >>>> result > > > > > > > >>>> > of > > > > > > > >>>> > > > > getValue is cached? > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > @Cacheable > > > > > > > >>>> > > > > int getValue(String name) { > > > > > > > >>>> > > > > return counters.computeIfAbsent(name, { 0 > }) > > > > > > > >>>> > > > > } > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > Regards, > > > > > > > >>>> > > > > Saikat > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > On Sat, Aug 15, 2020 at 7:21 PM Michael Pollind < > > > > > > > >>>> mpoll...@gmail.com> > > > > > > > >>>> > > > > wrote: > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > when you mean these annotations do you mean this > > > would > > > > > > need > > > > > > > >>>> to be > > > > > > > >>>> > > > > > implemented in ignite? > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > The project at the moment is split into multiple > > > > > modules. > > > > > > > >>>> > > ignite-core, > > > > > > > >>>> > > > > > ignite-cache, etc ... The plan was to also have > > > > > > ignite-data > > > > > > > >>>> but > > > > > > > >>>> > that > > > > > > > >>>> > > > will > > > > > > > >>>> > > > > > take a bit of work to get working correctly but > > the > > > > > basic > > > > > > > >>>> config is > > > > > > > >>>> > > > > mostly > > > > > > > >>>> > > > > > done. The plan is also to verify the API > described > > > in > > > > > the > > > > > > > >>>> wiki and > > > > > > > >>>> > > make > > > > > > > >>>> > > > > > sure this is what would work best. At the moment > > I'm > > > > > > missing > > > > > > > >>>> an > > > > > > > >>>> > > > > > implementation for the thin-cache and how that > > would > > > > fit > > > > > > > into > > > > > > > >>>> this > > > > > > > >>>> > > > > scheme. > > > > > > > >>>> > > > > > I've removed it due to the added complexity but > > I'm > > > > sure > > > > > > > >>>> something > > > > > > > >>>> > > > could > > > > > > > >>>> > > > > be > > > > > > > >>>> > > > > > arranged that would work. > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > For Ignite-cache, I have it as a separate module > > > that > > > > > can > > > > > > be > > > > > > > >>>> > > optionally > > > > > > > >>>> > > > > > included in a micronaut project where this > module > > > also > > > > > > has a > > > > > > > >>>> > > dependency > > > > > > > >>>> > > > > on > > > > > > > >>>> > > > > > micronaut-cache. The AsyncCache and SyncCache > are > > > the > > > > > two > > > > > > > >>>> > interfaces > > > > > > > >>>> > > > that > > > > > > > >>>> > > > > > micronaut-cache defines. There are two ways to > > > define > > > > > the > > > > > > > >>>> > > > implementation, > > > > > > > >>>> > > > > > you can either provide beans for AsyncCache and > > > > > SyncCache > > > > > > > but > > > > > > > >>>> they > > > > > > > >>>> > > also > > > > > > > >>>> > > > > > define a DynamicCacheManager that will use the > > name > > > of > > > > > the > > > > > > > >>>> instance > > > > > > > >>>> > > to > > > > > > > >>>> > > > > > refer to the name of the cache used. In the > > > > > documentation > > > > > > I > > > > > > > >>>> believe > > > > > > > >>>> > > for > > > > > > > >>>> > > > > > Teracotta you give a list of caches you want and > > > > > Hazelcast > > > > > > > >>>> > implements > > > > > > > >>>> > > > the > > > > > > > >>>> > > > > > DynamicCacheManager. you can see that in the > yaml > > > > > > > >>>> configuration in > > > > > > > >>>> > > > > > micronaut documentation where a list of cache > > names > > > > are > > > > > > > >>>> provided > > > > > > > >>>> > > along > > > > > > > >>>> > > > > with > > > > > > > >>>> > > > > > a configuration. Something similar can also be > > setup > > > > > > where a > > > > > > > >>>> list > > > > > > > >>>> > of > > > > > > > >>>> > > > > > implementations from the yaml can be mapped to a > > > > > > > >>>> configuration if > > > > > > > >>>> > > that > > > > > > > >>>> > > > > > would be more ideal. > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > https://github.com/pollend/micronaut-ignite/tree/feature/ > > > > > > rework/ignite-cache/src/main/java/io/micronaut/ignite > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > On Sat, Aug 15, 2020 at 4:10 PM Saikat Maitra < > > > > > > > >>>> > > saikat.mai...@gmail.com > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > wrote: > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > Hi Michael, > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > Welcome to the Ignite community!!! > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > Please feel free to reach out if you have any > > > > > questions > > > > > > > with > > > > > > > >>>> > > respect > > > > > > > >>>> > > > to > > > > > > > >>>> > > > > > > Ignite Integration. > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > I had a question specific to integration and > > > wanted > > > > to > > > > > > ask > > > > > > > >>>> if > > > > > > > >>>> > these > > > > > > > >>>> > > > > > > annotations also need to be implemented for > the > > > > > > > >>>> micronaut-ignite > > > > > > > >>>> > > > > > > integration. > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > @Cacheable - Indicates a method is cacheable > > > within > > > > > the > > > > > > > >>>> given > > > > > > > >>>> > cache > > > > > > > >>>> > > > > name > > > > > > > >>>> > > > > > > @CachePut - Indicates that the return value > of a > > > > > method > > > > > > > >>>> > invocation > > > > > > > >>>> > > > > should > > > > > > > >>>> > > > > > > be cached. Unlike @Cacheable the original > > > operation > > > > is > > > > > > > never > > > > > > > >>>> > > skipped. > > > > > > > >>>> > > > > > > @CacheInvalidate - Indicates the invocation > of a > > > > > method > > > > > > > >>>> should > > > > > > > >>>> > > cause > > > > > > > >>>> > > > > the > > > > > > > >>>> > > > > > > invalidation of one or many caches. > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > Denis - Thank you for sharing the details in > dev > > > > list, > > > > > > it > > > > > > > >>>> great > > > > > > > >>>> > to > > > > > > > >>>> > > > > learn > > > > > > > >>>> > > > > > > about micronaut-ignite module. > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > Regards, > > > > > > > >>>> > > > > > > Saikat > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > On Sat, Aug 15, 2020 at 12:35 AM Michael > > Pollind < > > > > > > > >>>> > > mpoll...@gmail.com > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > wrote: > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > Here is the page that i've stubbed out: > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > I'll start trying to fill out some of the > > > details > > > > > over > > > > > > > >>>> the next > > > > > > > >>>> > > few > > > > > > > >>>> > > > > > days > > > > > > > >>>> > > > > > > > and we can go from there. > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > On Fri, Aug 14, 2020 at 2:47 PM Denis Magda > < > > > > > > > >>>> dma...@apache.org > > > > > > > >>>> > > > > > > > > > >>>> > > > > wrote: > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > You're in, now you can create wiki pages > in > > > the > > > > > > Ignite > > > > > > > >>>> > > namespace. > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > Also, please subscribe to the list by > > sending > > > a > > > > > note > > > > > > > to > > > > > > > >>>> the > > > > > > > >>>> > > > > > > > > dev-subscr...@ignite.apache.org address. > > > > > Otherwise, > > > > > > > we > > > > > > > >>>> need > > > > > > > >>>> > to > > > > > > > >>>> > > > > > approve > > > > > > > >>>> > > > > > > > > every email you send. > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > - > > > > > > > >>>> > > > > > > > > Denis > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > On Fri, Aug 14, 2020 at 2:43 PM Michael > > > Pollind > > > > < > > > > > > > >>>> > > > > mpoll...@gmail.com> > > > > > > > >>>> > > > > > > > > wrote: > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> here is the link: > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > https://cwiki.apache.org/confluence/users/viewuserprofile.action > > ? > > > > > > username=mpollind > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> Here is the work in progress pull request > > > that > > > > > I've > > > > > > > put > > > > > > > >>>> > > > together: > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > https://github.com/micronaut-projects/micronaut-ignite/pull/33 > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > >> -- > > > > > > > >>>> > > > > > > > >> Sent from: > > > > > > > >>>> > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > >>>> > > > > > > > >> > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > - > > > > > Denis > > > > > > > > > > > > > > >
