search

eclipse / microprofile

Repository for important documentation - the index to the project / community
Apache License 2.0
673 stars 115 forks source link

OpenAPI document doesn't take into account multiple applications deployment #168

Open peterpz1 opened 4 years ago

peterpz1 commented 4 years ago

It would be a lot better to have openapi document per application, not single document per server, because it causes no possibility to use it when you have >1 application on server.

kenfinnigan commented 4 years ago

MicroProfile is designed around microservices, which aligns with single application per server.

What would be the use case for MicroProfile supporting multiple applications on a single server?

peterpz1 commented 4 years ago

So I don't know why our application server (Payara) in Full mode (not microprofile) is supporting this feature. In Full mode multiple applications are normal case, and since they implemented this feature in this mode it doesn't align properly with the assumption of single application.

kenfinnigan commented 4 years ago

So you agree it's an issue with Payara Full and not MicroProfile?

peterpz1 commented 4 years ago

Payara sent me here :) https://github.com/payara/Payara/issues/4470#issuecomment-590726272

phillip-kruger commented 4 years ago

I guess Wildfly and OpenLiberty will have the same issue.

kenfinnigan commented 4 years ago

@peterpz1 I'd consider this a Payara Full issue, and I don't see MicroProfile breaking away from the goal of microservices and single application/deployments

rdebusscher commented 4 years ago

I'm not sure this is a Payara issue only. We do, just as other runtimes, support MicroProfile specs in combination with the Jakarta specs. But the behavior of MicroProfile is not specified in the case when there are multiple applications deployed. So There is no behavior specified in case you use it that way.

Now that MicroProfile will go his own way, the intended behavior will need to be defined in the upcoming Jakarta OpenAPI Spec.

On Tue, 25 Feb 2020 at 10:40, Ken Finnigan notifications@github.com wrote:

@peterpz1 https://github.com/peterpz1 I'd consider this a Payara Full issue, and I don't see MicroProfile breaking away from the goal of microservices and single application/deployments

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/microprofile/issues/168?email_source=notifications&email_token=AAJL32KPVB674C63FNOCKETRETRPTA5CNFSM4K3BDQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM3IAUI#issuecomment-590774353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJL32PXVMVFTZB2QQH3WX3RETRPTANCNFSM4K3BDQUQ .

kenfinnigan commented 4 years ago

MicroProfile, as a whole, is based around the notion of microservices, and as such is aligned with a single deployment/application.

I believe "multiple" applications are explicitly not defined in specifications to allow implementations to handle this situation, if they so choose, without being precluded from doing so by the specification.

What upcoming Jakarta OpenAPI spec are you referring to?

rdebusscher commented 4 years ago

The fork of MP OpenAPI into Jakarta as discussed in the MP Hangout meetings about the technical alignment.

Jakarta will require some changes to the MP specs like for example the multiple application support. So it will be a fork of the code with adjustments to code and spec to accommodate Jakarta specifics.

On Tue, 25 Feb 2020 at 10:54, Ken Finnigan notifications@github.com wrote:

MicroProfile, as a whole, is based around the notion of microservices, and as such is aligned with a single deployment/application.

I believe "multiple" applications are explicitly not defined in specifications to allow implementations to handle this situation, if they so choose, without being precluded from doing so by the specification.

What upcoming Jakarta OpenAPI spec are you referring to?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse/microprofile/issues/168?email_source=notifications&email_token=AAJL32IZUKLGYLIJRA7YOJTRETTGXA5CNFSM4K3BDQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM3JYQA#issuecomment-590781504, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJL32IWPUTSZBNNC3MX4DDRETTGXANCNFSM4K3BDQUQ .

kenfinnigan commented 4 years ago

There is no fork at present.

My understanding was that the technical alignment discussion leads to Jakarta doing what it wants with MP specs. That doesn't automatically lead to Jakarta wanting OpenAPI, or am I missing something?

rdebusscher commented 4 years ago

There is no fork at present.

That is why I said 'upcoming'

That doesn't automatically lead to Jakarta wanting OpenAPI, or am I missing something?

Since MP specs are very popular in combination with Java EE/Jakarta EE that is a logical next step

MP config -> Jakarta config MP OpenAPI -> Jakarta OpenAPI MP Metrics -> Jakarta Metrics MP Rest Client -> Inclusion in Jakarta REST MP JWT Auth -> Inclusion in Jakarta Security API MP Health -> Jakarta Health ...

On Tue, 25 Feb 2020 at 11:09, Ken Finnigan notifications@github.com wrote:

There is no fork at present.

My understanding was that the technical alignment discussion leads to Jakarta doing what it wants with MP specs. That doesn't automatically lead to Jakarta wanting OpenAPI, or am I missing something?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse/microprofile/issues/168?email_source=notifications&email_token=AAJL32LAY5N4ZIWUOALJXK3RETU4VA5CNFSM4K3BDQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM3LIZY#issuecomment-590787687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJL32IKYJQGARLNBCONKC3RETU4VANCNFSM4K3BDQUQ .

kenfinnigan commented 4 years ago

Ok, just wanted to make sure I understood what you meant

rhuan080 commented 4 years ago

Hi, Wildfly has the same issue. Many of the MP specs are very interesting to the Jakarta EE apps and I think it is good to be possible to use it without fork the specs. In fact, the microservice is aligned with a single application per server, but I think the MP spec doesn't need to define it and keep it open to the implementation. Does It have any problem in keeping it open to the implementation?

Blubb324 commented 4 years ago

Hey, I also think that the support for multiple applications at one server is extremly useful. I know that the best behaviour for microservices is one artefact per server. But, image if there are really two little rest-apps - is it really necessary to build a complete microservice-architecture with docker/kubernetes and several servers (which are also using resources)? Another case is that sometimes you are limited by the clients (not every company is big enough to handle microservices) and they are just deploying several apps into one server.

Additionally it would be great if it wouldn´t be necessary to fork the specs - we all know the benefits of standards. :) On the other hand I can´t participate in this decision because I´m not close to the developement and I don´t know the code and what´s technical possible.

Thanks for your great work guys!

bfedoronchuk commented 3 years ago

It will be useful to support multiple OpenAPI files and endpoints for multiple API versions. For example: openapi-v1.yaml file -> /openapi-v1 endpoint openapi-v2.yaml file -> /openapi-v2 endpoint

peterpz1 commented 2 years ago

We are still in the same place 2 years later? Are there any decisions on the issue? On "full" type of servers when in the a lot of cases there are >1 apps there should be some solution for that...

Emily-Jiang commented 2 years ago

The spec has this clarification on multiple applications per server. I know Open Liberty has the support for multiple applications per server api doc generation.