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