1:48 p.m.
https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be cleaner to split
the subsystem in two, one for the server and another for the adapter.
2:12 p.m.
You may be right. I think the decision comes down to answering the
question, "Is it ever advantageous to have the server and adapter in the
same classloader space (module)?" The answer will hopefully become
clear once I get a chance to talk to you in more detail about seamless
adapter configuration.
I've got the client part working where a template configuration is
applied to any unsecured WAR. We just need to decide how the subsystem
will register the application with the server. That's the part where it
might be very helpful to have both in the same module so we can just
make direct calls. Even so, we can't really do that today without
significant refactoring.
On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might
be cleaner to split the subsystem in two, one for the server and another for the adapter.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:43 p.m.
If they are separate, why couldn't they be in the same classloader
space? They would share dependencies.
On 1/6/2015 8:12 AM, Stan Silvert wrote:
You may be right. I think the decision comes down to answering the
question, "Is it ever advantageous to have the server and adapter in the
same classloader space (module)?" The answer will hopefully become
clear once I get a chance to talk to you in more detail about seamless
adapter configuration.
I've got the client part working where a template configuration is
applied to any unsecured WAR. We just need to decide how the subsystem
will register the application with the server. That's the part where it
might be very helpful to have both in the same module so we can just
make direct calls. Even so, we can't really do that today without
significant refactoring.
On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be cleaner to
split the subsystem in two, one for the server and another for the adapter.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
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
2:51 p.m.
We should move all libs to modules, so would be same classloader space right? Module
class-loaders are shared by default are they not?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 6 January, 2015 2:43:12 PM
Subject: Re: [keycloak-dev] Splitting subsystem into two
If they are separate, why couldn't they be in the same classloader
space? They would share dependencies.
On 1/6/2015 8:12 AM, Stan Silvert wrote:
> You may be right. I think the decision comes down to answering the
> question, "Is it ever advantageous to have the server and adapter in the
> same classloader space (module)?" The answer will hopefully become
> clear once I get a chance to talk to you in more detail about seamless
> adapter configuration.
>
> I've got the client part working where a template configuration is
> applied to any unsecured WAR. We just need to decide how the subsystem
> will register the application with the server. That's the part where it
> might be very helpful to have both in the same module so we can just
> make direct calls. Even so, we can't really do that today without
> significant refactoring.
>
> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
>> cleaner to split the subsystem in two, one for the server and another for
>> the adapter.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3 p.m.
I'm not totally sure what can be shared among subsystems. Maybe I'm
overthinking it.
As long as the server is deployed as a WAR then there will be
restrictions on that by default. I don't know of any way to grab an
object from a WAR classloader and start making calls on it from a
subsystem. But maybe it can be done. I've never tried.
On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
We should move all libs to modules, so would be same classloader
space right? Module class-loaders are shared by default are they not?
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 6 January, 2015 2:43:12 PM
> Subject: Re: [keycloak-dev] Splitting subsystem into two
>
> If they are separate, why couldn't they be in the same classloader
> space? They would share dependencies.
>
> On 1/6/2015 8:12 AM, Stan Silvert wrote:
>> You may be right. I think the decision comes down to answering the
>> question, "Is it ever advantageous to have the server and adapter in the
>> same classloader space (module)?" The answer will hopefully become
>> clear once I get a chance to talk to you in more detail about seamless
>> adapter configuration.
>>
>> I've got the client part working where a template configuration is
>> applied to any unsecured WAR. We just need to decide how the subsystem
>> will register the application with the server. That's the part where it
>> might be very helpful to have both in the same module so we can just
>> make direct calls. Even so, we can't really do that today without
>> significant refactoring.
>>
>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
>>> cleaner to split the subsystem in two, one for the server and another for
>>> the adapter.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:07 p.m.
As long as shared code is in modules there should be no problem.
On 1/6/2015 9:00 AM, Stan Silvert wrote:
I'm not totally sure what can be shared among subsystems. Maybe
I'm
overthinking it.
As long as the server is deployed as a WAR then there will be
restrictions on that by default. I don't know of any way to grab an
object from a WAR classloader and start making calls on it from a
subsystem. But maybe it can be done. I've never tried.
On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
> We should move all libs to modules, so would be same classloader space right? Module
class-loaders are shared by default are they not?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 6 January, 2015 2:43:12 PM
>> Subject: Re: [keycloak-dev] Splitting subsystem into two
>>
>> If they are separate, why couldn't they be in the same classloader
>> space? They would share dependencies.
>>
>> On 1/6/2015 8:12 AM, Stan Silvert wrote:
>>> You may be right. I think the decision comes down to answering the
>>> question, "Is it ever advantageous to have the server and adapter in
the
>>> same classloader space (module)?" The answer will hopefully become
>>> clear once I get a chance to talk to you in more detail about seamless
>>> adapter configuration.
>>>
>>> I've got the client part working where a template configuration is
>>> applied to any unsecured WAR. We just need to decide how the subsystem
>>> will register the application with the server. That's the part where it
>>> might be very helpful to have both in the same module so we can just
>>> make direct calls. Even so, we can't really do that today without
>>> significant refactoring.
>>>
>>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
>>>> cleaner to split the subsystem in two, one for the server and another
for
>>>> the adapter.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
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
9:14 a.m.
As I see it there's two reasons to split the subsystem in two:
a) Reduce size of adapter dl
b) Make it more obvious to users that there are two parts
I'm not convinced it's required to split into two subsystems for either of those.
a) can be resolved by moving libs into modules and making sure we only include the
required modules for the adapter. b) can be resolved by making sure we have a sensible
error message if someone tries to start an auth-server with the adapter only dl.
So I reckon we don't split the subsystem, but leave as is. For 1.2.0.Beta1 we'll
move all jars from the WAR into modules and make sure only the required modules are
included in the adapter download.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 6 January, 2015 3:07:35 PM
Subject: Re: [keycloak-dev] Splitting subsystem into two
As long as shared code is in modules there should be no problem.
On 1/6/2015 9:00 AM, Stan Silvert wrote:
> I'm not totally sure what can be shared among subsystems. Maybe I'm
> overthinking it.
>
> As long as the server is deployed as a WAR then there will be
> restrictions on that by default. I don't know of any way to grab an
> object from a WAR classloader and start making calls on it from a
> subsystem. But maybe it can be done. I've never tried.
>
> On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
>> We should move all libs to modules, so would be same classloader space
>> right? Module class-loaders are shared by default are they not?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 6 January, 2015 2:43:12 PM
>>> Subject: Re: [keycloak-dev] Splitting subsystem into two
>>>
>>> If they are separate, why couldn't they be in the same classloader
>>> space? They would share dependencies.
>>>
>>> On 1/6/2015 8:12 AM, Stan Silvert wrote:
>>>> You may be right. I think the decision comes down to answering the
>>>> question, "Is it ever advantageous to have the server and adapter
in the
>>>> same classloader space (module)?" The answer will hopefully
become
>>>> clear once I get a chance to talk to you in more detail about seamless
>>>> adapter configuration.
>>>>
>>>> I've got the client part working where a template configuration is
>>>> applied to any unsecured WAR. We just need to decide how the subsystem
>>>> will register the application with the server. That's the part
where it
>>>> might be very helpful to have both in the same module so we can just
>>>> make direct calls. Even so, we can't really do that today without
>>>> significant refactoring.
>>>>
>>>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>>>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might
be
>>>>> cleaner to split the subsystem in two, one for the server and
another
>>>>> for
>>>>> the adapter.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3536
days inactive
3537
days old
6 comments
3 participants
participants (3)
-
Bill Burke -
Stan Silvert -
Stian Thorgersen