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/ >> > > > > > > > >> >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
