WebSockets Next: make it possible to perform logic before the HTTP upgrade is started about quarkus HOT 12 CLOSED

Looks very interesting and will help me with #40622. Thanks

from quarkus.

@michalvavrik We could also add a method to the interface to be able to filter the endpoints by id, i.e. io.quarkus.websockets.next.WebSocket.endpointId().

I like that, I can refactor #40873 to use that instead.

from quarkus.

Quarkus REST https://quarkus.io/guides/rest has https://javadoc.io/doc/io.quarkus.resteasy.reactive/resteasy-reactive/3.10.2/org/jboss/resteasy/reactive/server/ServerExceptionMapper.html that allows to register either global mapper for all the REST resources, or just for the one resources where the bean is produced.

For WS Next, it could be of interest to register this new interface for one endpoint only to avoid path-matching inside that bean.

from quarkus.

Maybe later though. Let's start with the global one.

from quarkus.

Maybe later though. Let's start with the global one.

Agreed. Let's start with the global one and improve later on (if needed ;-)

from quarkus.

Definitely +1 on focusing on global and then moving to per class

from quarkus.

Definitely +1 on focusing on global and then moving to per class

hey @geoand , yes as far as user beans go, but it would be ineffective to have a global bean applied on every endpoint and then start matching request with a bean to determine if you need to run it. If I need to secure just one endpoint of all, I think it's better to have a local endpoint specific. in #40873 I added build item for that, so it's Quarkus internal but it will exist.

from quarkus.

I'll have to have a look in a few days

from quarkus.

I'll have to have a look in a few days

sure, no hurry, thx

from quarkus.

👍🏼

from quarkus.

Definitely +1 on focusing on global and then moving to per class

hey @geoand , yes as far as user beans go, but it would be ineffective to have a global bean applied on every endpoint and then start matching request with a bean to determine if you need to run it. If I need to secure just one endpoint of all, I think it's better to have a local endpoint specific. in #40873 I added build item for that, so it's Quarkus internal but it will exist.

@michalvavrik We could also add a method to the interface to be able to filter the endpoints by id, i.e. io.quarkus.websockets.next.WebSocket.endpointId().

interface HttpUpgradePolicy {

   boolean appliesTo(String endpointId);

   Uni<CheckResult> checkUpgrade(HttpUpgradeContext context);
}

from quarkus.

Done.

from quarkus.