12:13 a.m.
Hello All,
We are finally close to finishing the Keycloak Quarkus Extension. An
extension that will help developers to protect their services using both
JVM and Native mode based on the existing functionality provided by our
adapters. In this case, by the Undertow Adapter.
After discussing with Scott Stark different approaches to this extension,
we finally have an agreement that will require two changes in the adapter
code.
The first one is quite simple as it is basically defining a constructor to
the KeycloakServletExtension in order to allow passing a pre-built
AdapterDeploymentContext instance [1]. This change will give more
flexibility to the extension to build the deployment context and use it to
configure the deployment. For instance, we could read keycloak related
settings from the Quarkus configuration instead of keycloak.json.
The second one is about lazy loading the HttpClient and to avoid creating a
new instance during the deployment configuration. But produce a new
instance only when a new instance is required. The main reason for this
change is to overcome some issues in Quarkus when generating native images
using the extension. Scott Stark started a thread [2] about this issue in
particular. In a nutshell, we are basically delaying the initialization of
HttpClient (and mainly its dependencies to some security related classes in
the JDK) to runtime.
Please, let me know what you think about these two changes, specially the
second one. I can not think about any issue that the lazy initialization of
the HttpClient can cause (considering concurrency issues), but maybe I'm
missing something.
[1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
[2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY
Regards,
Pedro Igor
12:19 a.m.
Btw, we are also depending on the following issue in Quarkus [3].
[3] https://github.com/quarkusio/quarkus/pull/1530
On Fri, Mar 15, 2019 at 8:13 PM Pedro Igor Silva <psilva(a)redhat.com> wrote:
Hello All,
We are finally close to finishing the Keycloak Quarkus Extension. An
extension that will help developers to protect their services using both
JVM and Native mode based on the existing functionality provided by our
adapters. In this case, by the Undertow Adapter.
After discussing with Scott Stark different approaches to this extension,
we finally have an agreement that will require two changes in the adapter
code.
The first one is quite simple as it is basically defining a constructor to
the KeycloakServletExtension in order to allow passing a pre-built
AdapterDeploymentContext instance [1]. This change will give more
flexibility to the extension to build the deployment context and use it to
configure the deployment. For instance, we could read keycloak related
settings from the Quarkus configuration instead of keycloak.json.
The second one is about lazy loading the HttpClient and to avoid creating
a new instance during the deployment configuration. But produce a new
instance only when a new instance is required. The main reason for this
change is to overcome some issues in Quarkus when generating native images
using the extension. Scott Stark started a thread [2] about this issue in
particular. In a nutshell, we are basically delaying the initialization of
HttpClient (and mainly its dependencies to some security related classes in
the JDK) to runtime.
Please, let me know what you think about these two changes, specially the
second one. I can not think about any issue that the lazy initialization of
the HttpClient can cause (considering concurrency issues), but maybe I'm
missing something.
[1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
[2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY
Regards,
Pedro Igor
1:43 a.m.
I think both changes are very reasonable, including the workaround for #2.
On Fri, Mar 15, 2019, 20:25 Pedro Igor Silva <psilva(a)redhat.com> wrote:
Btw, we are also depending on the following issue in Quarkus [3].
[3] https://github.com/quarkusio/quarkus/pull/1530
On Fri, Mar 15, 2019 at 8:13 PM Pedro Igor Silva <psilva(a)redhat.com>
wrote:
> Hello All,
>
> We are finally close to finishing the Keycloak Quarkus Extension. An
> extension that will help developers to protect their services using both
> JVM and Native mode based on the existing functionality provided by our
> adapters. In this case, by the Undertow Adapter.
>
> After discussing with Scott Stark different approaches to this extension,
> we finally have an agreement that will require two changes in the adapter
> code.
>
> The first one is quite simple as it is basically defining a constructor
to
> the KeycloakServletExtension in order to allow passing a pre-built
> AdapterDeploymentContext instance [1]. This change will give more
> flexibility to the extension to build the deployment context and use it
to
> configure the deployment. For instance, we could read keycloak related
> settings from the Quarkus configuration instead of keycloak.json.
>
> The second one is about lazy loading the HttpClient and to avoid creating
> a new instance during the deployment configuration. But produce a new
> instance only when a new instance is required. The main reason for this
> change is to overcome some issues in Quarkus when generating native
images
> using the extension. Scott Stark started a thread [2] about this issue in
> particular. In a nutshell, we are basically delaying the initialization
of
> HttpClient (and mainly its dependencies to some security related classes
in
> the JDK) to runtime.
>
> Please, let me know what you think about these two changes, specially the
> second one. I can not think about any issue that the lazy initialization
of
> the HttpClient can cause (considering concurrency issues), but maybe I'm
> missing something.
>
> [1] https://github.com/pedroigor/keycloak/tree/keycloak-adapter
> [2] https://groups.google.com/forum/#!topic/quarkus-dev/xVmL55tuWHY
>
> Regards,
> Pedro Igor
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1867
days inactive
1868
days old
2 comments
2 participants
participants (2)
-
Pedro Igor Silva -
Stefan Guilhen