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 >
