Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-27 Thread Andrey Gura
Hi,

Hmmm... It seems that [2] is just a marketing page that doesn't give
any arguments about the micronaut.

Anyway, security is a good point. Aleksandr, could you please add some
note to the IEP about security related value of the micronaut
framework?





On Thu, May 26, 2022 at 9:48 AM Mikhail Pochatkin
 wrote:
>
> Hello Igniters.
>
> I see that the main argument against Micronaut is that we need
> Micronaut+Swagger to achieve IEP 87 if we can use only Swagger. I agree
> this is a valid point and logically. But I think we can take a look into it
> from another side, from future vision. Main idea to start using micronaut
> to simplify code writing in future just because Micronaut Framework really
> helps to develop REST services in practice. For example, I think it's
> obvious that Ignite will need to implement some authentication mechanism
> and Micronaut can help to achieve it [1]. Moreover Micronaut is based on
> the same technology which is currently used in Ignite, I mean Netty. It
> means that we should speak only about vulnerabilities inside of Micronaut
> implementation, but the Micronaut project has a very big community and a
> lot of clients. In context of it I would say that bugs and vulnerabilities
> in Micronaut implementation will be found more quickly than in internal
> Ignite implementation with pure Netty. Another point about cloud native
> support [2] which also can be useful in the context of Ignite.
>
> [1] https://micronaut-projects.github.io/micronaut-security/latest/guide/
> [2] https://objectcomputing.com/expertise/cloud-engineering
>
> On Wed, May 25, 2022 at 6:45 PM Andrey Gura  wrote:
>
> > Why couldn't the handlers be annotated?
> >
> > I think Kirill Gusakov (as the feature contributor) can give some
> > ideas about what and how should be annotated. This may require some
> > tweaking.
> >
> > On Wed, May 25, 2022 at 6:06 PM Aleksandr Pakhomov 
> > wrote:
> > >
> > > Hi Alexander,
> > >
> > > Yes, swagger allows to annotate classes
> > > and then the spec will be generated. But
> > > here is a question. What classes should we
> > > annotade?
> > >
> > > Web framework brings the convention about
> > > how to write an endpoint and what to annotate.
> > > Our own REST server implementation does not.
> > > It is just the number of handlers.
> > >
> > > > On 25 May 2022, at 17:46, Alexander Polovtcev 
> > wrote:
> > > >
> > > > Aleksandr,
> > > >
> > > > Can we use these annotations without the micronaut dependencies? If
> > yes,
> > > > why do we need micronaut at all?
> > > >
> > > > On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov 
> > wrote:
> > > >
> > > >> Yes, swagger-core has its own set of annotations [1]
> > > >>
> > > >> [1]
> > > >>
> > https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
> > > >>
> > > >>> On 23 May 2022, at 12:37, Alexander Polovtcev <
> > alexpolovt...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I'm not that scared of having a big library, I just believe that it
> > might
> > > >>> be possible to avoid using it altogether. Don't swagger generators
> > have
> > > >>> their own annotations?
> > > >>
> > > >>
> > > >
> > >
> >


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Mikhail Pochatkin
Hello Igniters.

I see that the main argument against Micronaut is that we need
Micronaut+Swagger to achieve IEP 87 if we can use only Swagger. I agree
this is a valid point and logically. But I think we can take a look into it
from another side, from future vision. Main idea to start using micronaut
to simplify code writing in future just because Micronaut Framework really
helps to develop REST services in practice. For example, I think it's
obvious that Ignite will need to implement some authentication mechanism
and Micronaut can help to achieve it [1]. Moreover Micronaut is based on
the same technology which is currently used in Ignite, I mean Netty. It
means that we should speak only about vulnerabilities inside of Micronaut
implementation, but the Micronaut project has a very big community and a
lot of clients. In context of it I would say that bugs and vulnerabilities
in Micronaut implementation will be found more quickly than in internal
Ignite implementation with pure Netty. Another point about cloud native
support [2] which also can be useful in the context of Ignite.

[1] https://micronaut-projects.github.io/micronaut-security/latest/guide/
[2] https://objectcomputing.com/expertise/cloud-engineering

On Wed, May 25, 2022 at 6:45 PM Andrey Gura  wrote:

> Why couldn't the handlers be annotated?
>
> I think Kirill Gusakov (as the feature contributor) can give some
> ideas about what and how should be annotated. This may require some
> tweaking.
>
> On Wed, May 25, 2022 at 6:06 PM Aleksandr Pakhomov 
> wrote:
> >
> > Hi Alexander,
> >
> > Yes, swagger allows to annotate classes
> > and then the spec will be generated. But
> > here is a question. What classes should we
> > annotade?
> >
> > Web framework brings the convention about
> > how to write an endpoint and what to annotate.
> > Our own REST server implementation does not.
> > It is just the number of handlers.
> >
> > > On 25 May 2022, at 17:46, Alexander Polovtcev 
> wrote:
> > >
> > > Aleksandr,
> > >
> > > Can we use these annotations without the micronaut dependencies? If
> yes,
> > > why do we need micronaut at all?
> > >
> > > On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov 
> wrote:
> > >
> > >> Yes, swagger-core has its own set of annotations [1]
> > >>
> > >> [1]
> > >>
> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
> > >>
> > >>> On 23 May 2022, at 12:37, Alexander Polovtcev <
> alexpolovt...@gmail.com>
> > >> wrote:
> > >>>
> > >>> I'm not that scared of having a big library, I just believe that it
> might
> > >>> be possible to avoid using it altogether. Don't swagger generators
> have
> > >>> their own annotations?
> > >>
> > >>
> > >
> >
>


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Andrey Gura
Why couldn't the handlers be annotated?

I think Kirill Gusakov (as the feature contributor) can give some
ideas about what and how should be annotated. This may require some
tweaking.

On Wed, May 25, 2022 at 6:06 PM Aleksandr Pakhomov  wrote:
>
> Hi Alexander,
>
> Yes, swagger allows to annotate classes
> and then the spec will be generated. But
> here is a question. What classes should we
> annotade?
>
> Web framework brings the convention about
> how to write an endpoint and what to annotate.
> Our own REST server implementation does not.
> It is just the number of handlers.
>
> > On 25 May 2022, at 17:46, Alexander Polovtcev  
> > wrote:
> >
> > Aleksandr,
> >
> > Can we use these annotations without the micronaut dependencies? If yes,
> > why do we need micronaut at all?
> >
> > On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov  wrote:
> >
> >> Yes, swagger-core has its own set of annotations [1]
> >>
> >> [1]
> >> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
> >>
> >>> On 23 May 2022, at 12:37, Alexander Polovtcev 
> >> wrote:
> >>>
> >>> I'm not that scared of having a big library, I just believe that it might
> >>> be possible to avoid using it altogether. Don't swagger generators have
> >>> their own annotations?
> >>
> >>
> >
>


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Aleksandr Pakhomov
Hi Alexander, 

Yes, swagger allows to annotate classes
and then the spec will be generated. But 
here is a question. What classes should we 
annotade? 

Web framework brings the convention about 
how to write an endpoint and what to annotate. 
Our own REST server implementation does not. 
It is just the number of handlers. 

> On 25 May 2022, at 17:46, Alexander Polovtcev  wrote:
> 
> Aleksandr,
> 
> Can we use these annotations without the micronaut dependencies? If yes,
> why do we need micronaut at all?
> 
> On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov  wrote:
> 
>> Yes, swagger-core has its own set of annotations [1]
>> 
>> [1]
>> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
>> 
>>> On 23 May 2022, at 12:37, Alexander Polovtcev 
>> wrote:
>>> 
>>> I'm not that scared of having a big library, I just believe that it might
>>> be possible to avoid using it altogether. Don't swagger generators have
>>> their own annotations?
>> 
>> 
> 



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Andrey Gura
Agree with Alexander. I ask the same question in the vote thread.

On Wed, May 25, 2022 at 5:47 PM Alexander Polovtcev
 wrote:
>
> Aleksandr,
>
> Can we use these annotations without the micronaut dependencies? If yes,
> why do we need micronaut at all?
>
> On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov  wrote:
>
> > Yes, swagger-core has its own set of annotations [1]
> >
> > [1]
> > https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
> >
> > > On 23 May 2022, at 12:37, Alexander Polovtcev 
> > wrote:
> > >
> > > I'm not that scared of having a big library, I just believe that it might
> > > be possible to avoid using it altogether. Don't swagger generators have
> > > their own annotations?
> >
> >
>
> --
> With regards,
> Aleksandr Polovtcev


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Alexander Polovtcev
Aleksandr,

Can we use these annotations without the micronaut dependencies? If yes,
why do we need micronaut at all?

On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov  wrote:

> Yes, swagger-core has its own set of annotations [1]
>
> [1]
> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
>
> > On 23 May 2022, at 12:37, Alexander Polovtcev 
> wrote:
> >
> > I'm not that scared of having a big library, I just believe that it might
> > be possible to avoid using it altogether. Don't swagger generators have
> > their own annotations?
>
>

-- 
With regards,
Aleksandr Polovtcev


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-25 Thread Andrey Gura
> The main
functionality of micronaut framework is REST, so this
library is scanned for vulnerabilities regularly and fixes
them asap (looking to [1] it takes about a week).
I don't  think that Ignite REST server implementation
will be scanned as regular as micronaut and issues
will be fixed as quickly as micronaut does.

The problem is not the scan frequency. The actual problem is the
release cycle: somebody should fix a vulnerability in some dependency,
then that dependency should be released and in the end Ignite should
refresh dependencies and then should be released.

In absence of dependencies we just fix the problem and build a
maintenance release.

> As for autogenerated spec, I would mention that manual
spec writing introduces the second source of truth for
the API. So, implementation declares one API, spec
declares another API and there is no prooved contract
between them.

>From my point of view this is a bogus problem. Of course the described
situation is possible and often happens. But the presence of a
generation step does not protect against problems on other levels. I
can describe the interface correctly but implementation of this
interface can be wrong. So such instruments give just an illusion of
correctness. Where is the truth? In fact, no one knows.

On Fri, May 20, 2022 at 3:39 PM Aleksandr Pakhomov  wrote:
>
> Hi Andrey,
>
> Thank you for the valuable arguments.
>
> Speaking about micronaut, it is a popular library that
> provides a lot of build-in features like error handling,
> auth, IoC, test infrastructure, and many more. The main
> functionality of micronaut framework is REST, so this
> library is scanned for vulnerabilities regularly and fixes
> them asap (looking to [1] it takes about a week).
> I don't  think that Ignite REST server implementation
> will be scanned as regular as micronaut and issues
> will be fixed as quickly as micronaut does.
>
> As for autogenerated spec, I would mention that manual
> spec writing introduces the second source of truth for
> the API. So, implementation declares one API, spec
> declares another API and there is no prooved contract
> between them. For example, a developer adds "name"
> parameter to the existing endpoint and goes to the
> spec and adds "names" parameter there (makes a mistake).
> What is the right parameter here "name" or "names"?
> Also, if there won't be a compatibility test this mistake could
> go to the production and API spec consumers could get
> a REST client that is not compatible with the server.
>
>
> > On 19 May 2022, at 00:32, Andrey Gura  wrote:
> >
> > I personally don't support any additional 3rd party dependencies as
> > well as I don't fully understand the value of autogenerated specs for
> > REST endpoints. In my opinion we have another option: writing spec
> > manually. This option doesn't require any of proposed dependencies and
> > allow to avoid possible vulnerabilities. Of course at the cost of
> > manual actions.
> >
> > I understand that my statement is arguable. So I'll just wait for
> > opinions of other community members.
>


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-23 Thread Aleksandr Pakhomov
Yes, you are right about the usage of Jackson
in another modules. So, the “replacement” is 
not an argument any more.

> On 23 May 2022, at 12:37, Alexander Polovtcev  wrote:
> 
> My concern is that we will still use Jackson in other modules, like
> sql-engine, for example. Or will you replace this library completely in all
> modules?



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-23 Thread Aleksandr Pakhomov
Yes, swagger-core has its own set of annotations [1] 

[1] 
https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview

> On 23 May 2022, at 12:37, Alexander Polovtcev  wrote:
> 
> I'm not that scared of having a big library, I just believe that it might
> be possible to avoid using it altogether. Don't swagger generators have
> their own annotations?



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-23 Thread Alexander Polovtcev
> I get your concerns about additional library, but
micronaut itself is quite small.

I'm not that scared of having a big library, I just believe that it might
be possible to avoid using it altogether. Don't swagger generators have
their own annotations?

> The IEP replaces (that is
important) one with another and I’ll add this
information into the description.

My concern is that we will still use Jackson in other modules, like
sql-engine, for example. Or will you replace this library completely in all
modules?

On Fri, May 20, 2022 at 3:39 PM Aleksandr Pakhomov  wrote:

> Hi Andrey,
>
> Thank you for the valuable arguments.
>
> Speaking about micronaut, it is a popular library that
> provides a lot of build-in features like error handling,
> auth, IoC, test infrastructure, and many more. The main
> functionality of micronaut framework is REST, so this
> library is scanned for vulnerabilities regularly and fixes
> them asap (looking to [1] it takes about a week).
> I don't  think that Ignite REST server implementation
> will be scanned as regular as micronaut and issues
> will be fixed as quickly as micronaut does.
>
> As for autogenerated spec, I would mention that manual
> spec writing introduces the second source of truth for
> the API. So, implementation declares one API, spec
> declares another API and there is no prooved contract
> between them. For example, a developer adds "name"
> parameter to the existing endpoint and goes to the
> spec and adds "names" parameter there (makes a mistake).
> What is the right parameter here "name" or "names"?
> Also, if there won't be a compatibility test this mistake could
> go to the production and API spec consumers could get
> a REST client that is not compatible with the server.
>
>
> > On 19 May 2022, at 00:32, Andrey Gura  wrote:
> >
> > I personally don't support any additional 3rd party dependencies as
> > well as I don't fully understand the value of autogenerated specs for
> > REST endpoints. In my opinion we have another option: writing spec
> > manually. This option doesn't require any of proposed dependencies and
> > allow to avoid possible vulnerabilities. Of course at the cost of
> > manual actions.
> >
> > I understand that my statement is arguable. So I'll just wait for
> > opinions of other community members.
>
>

-- 
With regards,
Aleksandr Polovtcev


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-20 Thread Aleksandr Pakhomov
Hi Andrey,

Thank you for the valuable arguments.

Speaking about micronaut, it is a popular library that 
provides a lot of build-in features like error handling, 
auth, IoC, test infrastructure, and many more. The main 
functionality of micronaut framework is REST, so this 
library is scanned for vulnerabilities regularly and fixes 
them asap (looking to [1] it takes about a week). 
I don't  think that Ignite REST server implementation 
will be scanned as regular as micronaut and issues 
will be fixed as quickly as micronaut does.

As for autogenerated spec, I would mention that manual
spec writing introduces the second source of truth for 
the API. So, implementation declares one API, spec 
declares another API and there is no prooved contract
between them. For example, a developer adds "name" 
parameter to the existing endpoint and goes to the 
spec and adds "names" parameter there (makes a mistake). 
What is the right parameter here "name" or "names"? 
Also, if there won't be a compatibility test this mistake could 
go to the production and API spec consumers could get 
a REST client that is not compatible with the server.


> On 19 May 2022, at 00:32, Andrey Gura  wrote:
> 
> I personally don't support any additional 3rd party dependencies as
> well as I don't fully understand the value of autogenerated specs for
> REST endpoints. In my opinion we have another option: writing spec
> manually. This option doesn't require any of proposed dependencies and
> allow to avoid possible vulnerabilities. Of course at the cost of
> manual actions.
> 
> I understand that my statement is arguable. So I'll just wait for
> opinions of other community members.



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-19 Thread Aleksandr Pakhomov
Hi, Alexander 

Micronaut is chosen as a lightweight framework that 
is is compatible with swagger generators. One who 
develops an endpoint just writes a regular micronaut 
annotations and gets specification generated from it. 

I get your concerns about additional library, but 
micronaut itself is quite small. 

As for serialisation lib, current implementation uses
jackson-databind that has some drawbacks like
possible security issues (CVE) due to its dynamic
nature. Micronaut serde does nothing at runtime 
and is small enough. The IEP replaces (that is 
important) one with another and I’ll add this
information into the description.

> On 19 May 2022, at 13:17, Alexander Polovtcev  wrote:
> 
> Hello, Aleksandr!
> 
> I agree with the usage of Swagger for generating REST API specifications as
> it, for example, removes the burden of manually keeping the documentation
> up to date. However, why do we need the Micronaut framework? No other
> modules use it, and it brings a lot of dependencies that you will have to
> shadow somehow. AFAIK current implementation uses a pure Netty approach and
> is quite small in size. My other concern is using Micronaut serde for
> serialization. We already have other serialization libraries as
> dependencies and do we really need another one?
> 
> On Thu, May 19, 2022 at 1:06 PM Aleksandr Pakhomov  wrote:
> 
>> Hi, Eduard
>> 
>> Thank you for pointing out the 140 symbol column limit.
>> Il’l follow this.
>> 
>> As for transitive dependencies, good point. I would mention
>> that not only class loader magic can be implemented but
>> Micronaut libraries could be shadowed in order not to
>> cause the jar-hell issues for clients.
>> 
>>> On 19 May 2022, at 01:40, Eduard Rakhmankulov 
>> wrote:
>>> 
>>> Hi, Igniters!
>>> 
>>> I am really glad about the 140 symbol column limit.
>>> 
>>> But aside from possible vulnerabilities mentioned above I have other
>>> concerns, which may affect some future users.
>>> 
>>> Micronaut is a rather popular framework. Are we planning some OSGI
>> support
>>> (or custom classloader magic) so users which have been already using
>>> micronaut don't need to be bound to the version transitively inherited by
>>> ignite dependencies?
>>> 
>>> On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:
>>> 
 I personally don't support any additional 3rd party dependencies as
 well as I don't fully understand the value of autogenerated specs for
 REST endpoints. In my opinion we have another option: writing spec
 manually. This option doesn't require any of proposed dependencies and
 allow to avoid possible vulnerabilities. Of course at the cost of
 manual actions.
 
 I understand that my statement is arguable. So I'll just wait for
 opinions of other community members.
 
 On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
 wrote:
> 
> 
> Hello, Igniters.
> 
> I would like to start a discussion about Java Code Style Guide [1]
 changes that are going to be a part of IEP-87 [2] implementation. The
>> set
 of libraries and frameworks that are going to be allowed to be used in
 production:
>   - Micronaut for REST Server [3]
>   - Swagger for Open API annotations [4]
>   - Micronaut serde for REST serialization [5]
> 
> Any objections? Also, comments on IEP-87 are welcomed.
> [1]
 
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
 <
 
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> 
> [2]
 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
 <
 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> 
> [3] https://micronaut.io/docs /
> [4] https://swagger.io 
> [5]
 
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
 <
 
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> /
 
>> 
>> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-19 Thread Alexander Polovtcev
Hello, Aleksandr!

I agree with the usage of Swagger for generating REST API specifications as
it, for example, removes the burden of manually keeping the documentation
up to date. However, why do we need the Micronaut framework? No other
modules use it, and it brings a lot of dependencies that you will have to
shadow somehow. AFAIK current implementation uses a pure Netty approach and
is quite small in size. My other concern is using Micronaut serde for
serialization. We already have other serialization libraries as
dependencies and do we really need another one?

On Thu, May 19, 2022 at 1:06 PM Aleksandr Pakhomov  wrote:

> Hi, Eduard
>
> Thank you for pointing out the 140 symbol column limit.
> Il’l follow this.
>
> As for transitive dependencies, good point. I would mention
> that not only class loader magic can be implemented but
> Micronaut libraries could be shadowed in order not to
> cause the jar-hell issues for clients.
>
> > On 19 May 2022, at 01:40, Eduard Rakhmankulov 
> wrote:
> >
> > Hi, Igniters!
> >
> > I am really glad about the 140 symbol column limit.
> >
> > But aside from possible vulnerabilities mentioned above I have other
> > concerns, which may affect some future users.
> >
> > Micronaut is a rather popular framework. Are we planning some OSGI
> support
> > (or custom classloader magic) so users which have been already using
> > micronaut don't need to be bound to the version transitively inherited by
> > ignite dependencies?
> >
> > On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:
> >
> >> I personally don't support any additional 3rd party dependencies as
> >> well as I don't fully understand the value of autogenerated specs for
> >> REST endpoints. In my opinion we have another option: writing spec
> >> manually. This option doesn't require any of proposed dependencies and
> >> allow to avoid possible vulnerabilities. Of course at the cost of
> >> manual actions.
> >>
> >> I understand that my statement is arguable. So I'll just wait for
> >> opinions of other community members.
> >>
> >> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
> >> wrote:
> >>>
> >>>
> >>> Hello, Igniters.
> >>>
> >>> I would like to start a discussion about Java Code Style Guide [1]
> >> changes that are going to be a part of IEP-87 [2] implementation. The
> set
> >> of libraries and frameworks that are going to be allowed to be used in
> >> production:
> >>>- Micronaut for REST Server [3]
> >>>- Swagger for Open API annotations [4]
> >>>- Micronaut serde for REST serialization [5]
> >>>
> >>> Any objections? Also, comments on IEP-87 are welcomed.
> >>> [1]
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> >> <
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> >>>
> >>> [2]
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> >> <
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> >>>
> >>> [3] https://micronaut.io/docs /
> >>> [4] https://swagger.io 
> >>> [5]
> >>
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> >> <
> >>
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> >>> /
> >>
>
>

-- 
With regards,
Aleksandr Polovtcev


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-19 Thread Aleksandr Pakhomov
Hi, Eduard

Thank you for pointing out the 140 symbol column limit.
Il’l follow this.

As for transitive dependencies, good point. I would mention
that not only class loader magic can be implemented but 
Micronaut libraries could be shadowed in order not to 
cause the jar-hell issues for clients.

> On 19 May 2022, at 01:40, Eduard Rakhmankulov  wrote:
> 
> Hi, Igniters!
> 
> I am really glad about the 140 symbol column limit.
> 
> But aside from possible vulnerabilities mentioned above I have other
> concerns, which may affect some future users.
> 
> Micronaut is a rather popular framework. Are we planning some OSGI support
> (or custom classloader magic) so users which have been already using
> micronaut don't need to be bound to the version transitively inherited by
> ignite dependencies?
> 
> On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:
> 
>> I personally don't support any additional 3rd party dependencies as
>> well as I don't fully understand the value of autogenerated specs for
>> REST endpoints. In my opinion we have another option: writing spec
>> manually. This option doesn't require any of proposed dependencies and
>> allow to avoid possible vulnerabilities. Of course at the cost of
>> manual actions.
>> 
>> I understand that my statement is arguable. So I'll just wait for
>> opinions of other community members.
>> 
>> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
>> wrote:
>>> 
>>> 
>>> Hello, Igniters.
>>> 
>>> I would like to start a discussion about Java Code Style Guide [1]
>> changes that are going to be a part of IEP-87 [2] implementation. The set
>> of libraries and frameworks that are going to be allowed to be used in
>> production:
>>>- Micronaut for REST Server [3]
>>>- Swagger for Open API annotations [4]
>>>- Micronaut serde for REST serialization [5]
>>> 
>>> Any objections? Also, comments on IEP-87 are welcomed.
>>> [1]
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>> 
>>> [2]
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>> 
>>> [3] https://micronaut.io/docs /
>>> [4] https://swagger.io 
>>> [5]
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>> <
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>>> /
>> 



Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-18 Thread Eduard Rakhmankulov
Hi, Igniters!

I am really glad about the 140 symbol column limit.

But aside from possible vulnerabilities mentioned above I have other
concerns, which may affect some future users.

Micronaut is a rather popular framework. Are we planning some OSGI support
(or custom classloader magic) so users which have been already using
micronaut don't need to be bound to the version transitively inherited by
ignite dependencies?

On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:

> I personally don't support any additional 3rd party dependencies as
> well as I don't fully understand the value of autogenerated specs for
> REST endpoints. In my opinion we have another option: writing spec
> manually. This option doesn't require any of proposed dependencies and
> allow to avoid possible vulnerabilities. Of course at the cost of
> manual actions.
>
> I understand that my statement is arguable. So I'll just wait for
> opinions of other community members.
>
> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
> wrote:
> >
> >
> > Hello, Igniters.
> >
> > I would like to start a discussion about Java Code Style Guide [1]
> changes that are going to be a part of IEP-87 [2] implementation. The set
> of libraries and frameworks that are going to be allowed to be used in
> production:
> > - Micronaut for REST Server [3]
> > - Swagger for Open API annotations [4]
> > - Micronaut serde for REST serialization [5]
> >
> > Any objections? Also, comments on IEP-87 are welcomed.
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> <
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> >
> > [2]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> <
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> >
> > [3] https://micronaut.io/docs /
> > [4] https://swagger.io 
> > [5]
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> <
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> >/
>


Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-18 Thread Andrey Gura
I personally don't support any additional 3rd party dependencies as
well as I don't fully understand the value of autogenerated specs for
REST endpoints. In my opinion we have another option: writing spec
manually. This option doesn't require any of proposed dependencies and
allow to avoid possible vulnerabilities. Of course at the cost of
manual actions.

I understand that my statement is arguable. So I'll just wait for
opinions of other community members.

On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov  wrote:
>
>
> Hello, Igniters.
>
> I would like to start a discussion about Java Code Style Guide [1] changes 
> that are going to be a part of IEP-87 [2] implementation. The set of 
> libraries and frameworks that are going to be allowed to be used in 
> production:
> - Micronaut for REST Server [3]
> - Swagger for Open API annotations [4]
> - Micronaut serde for REST serialization [5]
>
> Any objections? Also, comments on IEP-87 are welcomed.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>  
> 
> [2] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>  
> 
> [3] https://micronaut.io/docs /
> [4] https://swagger.io 
> [5] 
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide 
> /


[DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-16 Thread Aleksandr Pakhomov

Hello, Igniters.

I would like to start a discussion about Java Code Style Guide [1] changes that 
are going to be a part of IEP-87 [2] implementation. The set of libraries and 
frameworks that are going to be allowed to be used in production:
- Micronaut for REST Server [3] 
- Swagger for Open API annotations [4] 
- Micronaut serde for REST serialization [5] 

Any objections? Also, comments on IEP-87 are welcomed. 
[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
 

 
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
 

 
[3] https://micronaut.io/docs / 
[4] https://swagger.io  
[5] https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide 
/

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-06 Thread Andrey Gura
Aleksandr,

it would be better to finish the IEP draft and then start a discussion
thread on dev list. At the moment I see TBD sections and it makes
impossible to have a full view about the proposal.

Thanks!

On Fri, May 6, 2022 at 6:11 PM Aleksandr Pakhomov  wrote:
>
> Hello, Igniters.
>
> I'd like to add a few 3rd party libraries to Ignite 3 Java Code Style Guide 
> [1]. As I mentioned in IEP-87 [2], it will be:
> Micrionaut for REST [3]
> Swagger for Open API annotations [4]
> Micronaut serde for REST serialization [5]
>
> WDYT? Any objections? Also, comments on IEP-87 are welcomed.
>
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> [2] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> [3] https://micronaut.io/docs/
> [4] https://swagger.io
> [5] 
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide/
>
> --
> Best regards,
> Aleksandr Pakhomov


[DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

2022-05-06 Thread Aleksandr Pakhomov
Hello, Igniters. 

I'd like to add a few 3rd party libraries to Ignite 3 Java Code Style Guide 
[1]. As I mentioned in IEP-87 [2], it will be: 
Micrionaut for REST [3]
Swagger for Open API annotations [4]
Micronaut serde for REST serialization [5]

WDYT? Any objections? Also, comments on IEP-87 are welcomed.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
[3] https://micronaut.io/docs/
[4] https://swagger.io
[5] https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide/

--
Best regards, 
Aleksandr Pakhomov