9:54 a.m.
As I said to make sure we're all on the same page here's my view on what we've
just discussed:
1. A user creates a module for the provider
2. The user copies the module into '/modules'
3. The user registers the module with the auth-server subsystem. This can be done either
by directly editing standalone.xml or through CLI. Example snippet from standalone.xml
would look like:
<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
<auth-server name="main-auth-server">
<enabled>true</enabled>
<web-context>auth</web-context>
<providers>
<module name="org.acme.userprovider" />
<module name="org.acme.anotherprovider" />
</providers>
</auth-server>
</subsystem>
4. When a new provider module is registered Keycloak would need to be reloaded
This will require some changes to how Keycloak loads/finds providers as it needs to not
only look in its own ClassPath for providers, but also in all ModuleClassPath that is
referenced in the subsystem.
10:15 a.m.
On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
As I said to make sure we're all on the same page here's my
view on what we've just discussed:
1. A user creates a module for the provider
2. The user copies the module into '/modules'
3. The user registers the module with the auth-server subsystem. This can be done either
by directly editing standalone.xml or through CLI. Example snippet from standalone.xml
would look like:
<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
<auth-server name="main-auth-server">
<enabled>true</enabled>
<web-context>auth</web-context>
<providers>
<module name="org.acme.userprovider" />
<module name="org.acme.anotherprovider" />
</providers>
</auth-server>
</subsystem>
4. When a new provider module is registered Keycloak would need to be reloaded
Don't you have to restart the entire server if you add a new module?
This should work too, with no code changes, no funky classloading:
1. Move all keycloak archives to modules
2. add jboss-deployment-structure.xml to embedded WAR
3. add a "keycloak-providers" module that only contains a module.xml
definition
4. User creates a module for the provider
5. User edits keycloak-providers module.xml file importing the user module
6. restart server.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:38 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, January 20, 2015 11:15:55 AM
Subject: Re: [keycloak-dev] Provider modules
On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
As I said to make sure we're all on the same page here's my
view on what we've just discussed:
1. A user creates a module for the provider
2. The user copies the module into '/modules'
3. The user registers the module with the auth-server subsystem. This can be done either
by directly editing standalone.xml or through CLI. Example snippet from standalone.xml
would look like:
<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
<auth-server name="main-auth-server">
<enabled>true</enabled>
<web-context>auth</web-context>
<providers>
<module name="org.acme.userprovider" />
<module name="org.acme.anotherprovider" />
</providers>
</auth-server>
</subsystem>
4. When a new provider module is registered Keycloak would need to be reloaded
Don't you have to restart the entire server if you add a new
module?
I'm 99% sure that you don't have to restart the whole server. Just redeploying
the WAR should do the trick.
This should work too, with no code changes, no funky classloading:
1. Move all keycloak archives to modules
2. add jboss-deployment-structure.xml to embedded WAR
3. add a "keycloak-providers" module that only contains a module.xml
definition
4. User creates a module for the provider
5. User edits keycloak-providers module.xml file importing the user module
6. restart server.
Yes, that will work too. But long term, I think we should do what Stian is talking about.
The EJB subsystem does the same thing. It allows you to add global modules in
standalone.xml.
Also, if we want to support two kc servers in the same domain with different configs, we
can't let them edit jboss-deployment-structure.xml.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:17 a.m.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, January 20, 2015 11:38:22 AM
Subject: Re: [keycloak-dev] Provider modules
Also, if we want to support two kc servers in the same domain with
different configs, we can't let them edit jboss-deployment-structure.xml.
This may bear further explanation. With the subsystem, we allow you to define as many
keycloak servers as you want. These run completely independently. As far as the domain
is concerned, they are two completely different deployments and you can provision them to
run on whatever servers each is assigned to. But if you change something inside the WAR,
it will affect every keycloak server you define.
11:03 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 20 January, 2015 5:15:55 PM
Subject: Re: [keycloak-dev] Provider modules
On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
> As I said to make sure we're all on the same page here's my view on what
> we've just discussed:
>
> 1. A user creates a module for the provider
> 2. The user copies the module into '/modules'
> 3. The user registers the module with the auth-server subsystem. This can
> be done either by directly editing standalone.xml or through CLI. Example
> snippet from standalone.xml would look like:
>
> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
> <auth-server name="main-auth-server">
> <enabled>true</enabled>
> <web-context>auth</web-context>
> <providers>
> <module name="org.acme.userprovider" />
> <module name="org.acme.anotherprovider" />
> </providers>
> </auth-server>
> </subsystem>
>
> 4. When a new provider module is registered Keycloak would need to be
> reloaded
>
Don't you have to restart the entire server if you add a new module?
This should work too, with no code changes, no funky classloading:
1. Move all keycloak archives to modules
2. add jboss-deployment-structure.xml to embedded WAR
3. add a "keycloak-providers" module that only contains a module.xml
definition
4. User creates a module for the provider
5. User edits keycloak-providers module.xml file importing the user module
6. restart server.
Why would you need jboss-deployment-structure.xml to embedded WAR?
The problem with that approach is that all providers are loaded from the same class-loader
so there would be issues if providers use different versions of the same library. I also
think it would be more natural for a WildFly user to edit standalone.xml or use the CLI
than to add dependencies to an existing module. Finally another issue happens when someone
upgrades/patches Keycloak, would they not then override the keycloak-providers module.xml
and have to add everything again?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:24 a.m.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, January 20, 2015 12:03:59 PM
Subject: Re: [keycloak-dev] Provider modules
Why would you need jboss-deployment-structure.xml to embedded WAR?
The problem with that approach is that all providers are loaded from
the same class-loader so there would be issues if providers use different versions of the
same library. I also think it would be more natural for a WildFly user to edit
standalone.xml or use the CLI than to add dependencies to an existing module. Finally
another issue happens when someone upgrades/patches Keycloak, would they not then override
the keycloak-providers module.xml and have to add everything again?
Yes they would. That's another reason why, in general, hacking the WAR (or anything
else we ship) is a bad idea.
Plus, it drives the support guys absolutely nuts!
11:42 a.m.
I'm just saying that editing a module.xml file requires no code changes
and we can ship 1.1.
Bill
On 1/20/2015 12:24 PM, Stan Silvert wrote:
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, January 20, 2015 12:03:59 PM
Subject: Re: [keycloak-dev] Provider modules
> Why would you need jboss-deployment-structure.xml to embedded WAR?
> The problem with that approach is that all providers are loaded from the same
class-loader so there would be issues if providers use different versions of the same
library. I also think it would be more natural for a WildFly user to edit standalone.xml
or use the CLI than to add dependencies to an existing module. Finally another issue
happens when someone upgrades/patches Keycloak, would they not then override the
keycloak-providers module.xml and have to add everything again?
Yes they would. That's another reason why, in general, hacking the WAR (or anything
else we ship) is a bad idea.
Plus, it drives the support guys absolutely nuts!
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:35 p.m.
Yo, still working on separation into modules, but...
Right now, we deploy our JPA plugins via the container deployer as part
of the WAR. Not sure if that the deployer will pick up these JPA
plugins if they are in an imported module.
On 1/20/2015 12:42 PM, Bill Burke wrote:
I'm just saying that editing a module.xml file requires no code
changes
and we can ship 1.1.
Bill
On 1/20/2015 12:24 PM, Stan Silvert wrote:
>
>
> ----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, January 20, 2015 12:03:59 PM
> Subject: Re: [keycloak-dev] Provider modules
>
>
>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>
>> The problem with that approach is that all providers are loaded from the same
class-loader so there would be issues if providers use different versions of the same
library. I also think it would be more natural for a WildFly user to edit standalone.xml
or use the CLI than to add dependencies to an existing module. Finally another issue
happens when someone upgrades/patches Keycloak, would they not then override the
keycloak-providers module.xml and have to add everything again?
>
> Yes they would. That's another reason why, in general, hacking the WAR (or
anything else we ship) is a bad idea.
>
> Plus, it drives the support guys absolutely nuts!
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:15 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 20 January, 2015 10:35:52 PM
Subject: Re: [keycloak-dev] Provider modules
Yo, still working on separation into modules, but...
Right now, we deploy our JPA plugins via the container deployer as part
of the WAR. Not sure if that the deployer will pick up these JPA
plugins if they are in an imported module.
What's a JPA plugin? We manage everything JPA ourselves so what does it have to do
with the deployer?
On 1/20/2015 12:42 PM, Bill Burke wrote:
> I'm just saying that editing a module.xml file requires no code changes
> and we can ship 1.1.
>
> Bill
>
>
> On 1/20/2015 12:24 PM, Stan Silvert wrote:
>>
>>
>> ----- Original Message -----
>> From: "Stian Thorgersen" <stian(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, January 20, 2015 12:03:59 PM
>> Subject: Re: [keycloak-dev] Provider modules
>>
>>
>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>>
>>> The problem with that approach is that all providers are loaded from the
>>> same class-loader so there would be issues if providers use different
>>> versions of the same library. I also think it would be more natural for
>>> a WildFly user to edit standalone.xml or use the CLI than to add
>>> dependencies to an existing module. Finally another issue happens when
>>> someone upgrades/patches Keycloak, would they not then override the
>>> keycloak-providers module.xml and have to add everything again?
>>
>> Yes they would. That's another reason why, in general, hacking the WAR
>> (or anything else we ship) is a bad idea.
>>
>> Plus, it drives the support guys absolutely nuts!
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:44 a.m.
Ah cool! We do! Sorry, I thought JPA was deployed by deployer.
On 1/21/2015 1:15 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 20 January, 2015 10:35:52 PM
> Subject: Re: [keycloak-dev] Provider modules
>
> Yo, still working on separation into modules, but...
>
> Right now, we deploy our JPA plugins via the container deployer as part
> of the WAR. Not sure if that the deployer will pick up these JPA
> plugins if they are in an imported module.
What's a JPA plugin? We manage everything JPA ourselves so what does it have to do
with the deployer?
>
> On 1/20/2015 12:42 PM, Bill Burke wrote:
>> I'm just saying that editing a module.xml file requires no code changes
>> and we can ship 1.1.
>>
>> Bill
>>
>>
>> On 1/20/2015 12:24 PM, Stan Silvert wrote:
>>>
>>>
>>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian(a)redhat.com>
>>> To: "Bill Burke" <bburke(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, January 20, 2015 12:03:59 PM
>>> Subject: Re: [keycloak-dev] Provider modules
>>>
>>>
>>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>>>
>>>> The problem with that approach is that all providers are loaded from the
>>>> same class-loader so there would be issues if providers use different
>>>> versions of the same library. I also think it would be more natural for
>>>> a WildFly user to edit standalone.xml or use the CLI than to add
>>>> dependencies to an existing module. Finally another issue happens when
>>>> someone upgrades/patches Keycloak, would they not then override the
>>>> keycloak-providers module.xml and have to add everything again?
>>>
>>> Yes they would. That's another reason why, in general, hacking the WAR
>>> (or anything else we ship) is a bad idea.
>>>
>>> Plus, it drives the support guys absolutely nuts!
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:48 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 21 January, 2015 3:44:49 PM
Subject: Re: [keycloak-dev] Provider modules
Ah cool! We do! Sorry, I thought JPA was deployed by deployer.
Nope - in fact we've got work-arounds to prevent the deployer to meddle with our stuff
;)
The less the deployment processors do for us the better as we want to be in control! For
example CDI and web services sub-subsystems are both bothering us from time to time, even
though we use neither.
On 1/21/2015 1:15 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 20 January, 2015 10:35:52 PM
>> Subject: Re: [keycloak-dev] Provider modules
>>
>> Yo, still working on separation into modules, but...
>>
>> Right now, we deploy our JPA plugins via the container deployer as part
>> of the WAR. Not sure if that the deployer will pick up these JPA
>> plugins if they are in an imported module.
>
> What's a JPA plugin? We manage everything JPA ourselves so what does it
> have to do with the deployer?
>
>>
>> On 1/20/2015 12:42 PM, Bill Burke wrote:
>>> I'm just saying that editing a module.xml file requires no code changes
>>> and we can ship 1.1.
>>>
>>> Bill
>>>
>>>
>>> On 1/20/2015 12:24 PM, Stan Silvert wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian(a)redhat.com>
>>>> To: "Bill Burke" <bburke(a)redhat.com>
>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>> Sent: Tuesday, January 20, 2015 12:03:59 PM
>>>> Subject: Re: [keycloak-dev] Provider modules
>>>>
>>>>
>>>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>>>>
>>>>> The problem with that approach is that all providers are loaded
from
>>>>> the
>>>>> same class-loader so there would be issues if providers use
different
>>>>> versions of the same library. I also think it would be more natural
for
>>>>> a WildFly user to edit standalone.xml or use the CLI than to add
>>>>> dependencies to an existing module. Finally another issue happens
when
>>>>> someone upgrades/patches Keycloak, would they not then override the
>>>>> keycloak-providers module.xml and have to add everything again?
>>>>
>>>> Yes they would. That's another reason why, in general, hacking the
WAR
>>>> (or anything else we ship) is a bad idea.
>>>>
>>>> Plus, it drives the support guys absolutely nuts!
>>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3380
days inactive
3381
days old
10 comments
3 participants
participants (3)
-
Bill Burke -
Stan Silvert -
Stian Thorgersen