12:21 a.m.
Hi Stian,
do you know what parts of JavaEE Web libraries, LiveOak does not want
to use?
Right now, I know LiveOak uses Jax-RS and WebSockets.
Does it use CDI, Servlets?
Regards,
Anil
9:41 a.m.
That's an open question at the moment, but I would be surprised if LiveOak itself
starts using any JavaEE libraries. Currently, Keycloak and AeroGear UPS are deployed
separately (as WARs) on the same WildFly instance.
In the future I would like to see both of those deployed as WildFly extensions. I've
in the past done WildFly extensions with JAX-RS and Servlets, which worked quite well, but
I don't think CDI would.
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 15 May, 2014 11:21:29 PM
Subject: [keycloak-dev] LiveOak and JavaEE libraries
Hi Stian,
do you know what parts of JavaEE Web libraries, LiveOak does not want
to use?
Right now, I know LiveOak uses Jax-RS and WebSockets.
Does it use CDI, Servlets?
Regards,
Anil
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:04 a.m.
Yes, the intention is that LiveOak doesn't require JEE container. We
started with pure netty container. Currently we deploy on WildFly for
several reasons, also because of KeyCloak. However we want to start
stripping it down as soon as WildFly Core is available.
Btw. LiveOak has a mailing list: http://liveoak.io/community/
On 05/16/2014 09:41 AM, Stian Thorgersen wrote:
That's an open question at the moment, but I would be surprised
if
LiveOak itself starts using any JavaEE libraries. Currently, Keycloak
and AeroGear UPS are deployed separately (as WARs) on the same
WildFly instance.
In the future I would like to see both of those deployed as WildFly
extensions. I've in the past done WildFly extensions with JAX-RS and
Servlets, which worked quite well, but I don't think CDI would.
----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com> To:
> keycloak-dev(a)lists.jboss.org Sent: Thursday, 15 May, 2014 11:21:29
> PM Subject: [keycloak-dev] LiveOak and JavaEE libraries
>
> Hi Stian, do you know what parts of JavaEE Web libraries, LiveOak
> does not want to use?
>
> Right now, I know LiveOak uses Jax-RS and WebSockets.
>
> Does it use CDI, Servlets?
>
> Regards, Anil _______________________________________________
> 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
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead
2:23 p.m.
On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
Yes, the intention is that LiveOak doesn't require JEE container.
We
started with pure netty container. Currently we deploy on WildFly for
several reasons, also because of KeyCloak. However we want to start
stripping it down as soon as WildFly Core is available.
I'm working on
"Keycloak without servlets" right now. The goal is to be
able to use Keycloak for the EAP console where servlets are verboten.
So far so good.
But it begs the question, "Since the Servlet API is mostly just a facade
on top of the Undertow API, why do we care if Keycloak is using the
Servlet API?"
Btw. LiveOak has a mailing list: http://liveoak.io/community/
On 05/16/2014 09:41 AM, Stian Thorgersen wrote:
> That's an open question at the moment, but I would be surprised if
> LiveOak itself starts using any JavaEE libraries. Currently, Keycloak
> and AeroGear UPS are deployed separately (as WARs) on the same
> WildFly instance.
>
> In the future I would like to see both of those deployed as WildFly
> extensions. I've in the past done WildFly extensions with JAX-RS and
> Servlets, which worked quite well, but I don't think CDI would.
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com> To:
>> keycloak-dev(a)lists.jboss.org Sent: Thursday, 15 May, 2014 11:21:29
>> PM Subject: [keycloak-dev] LiveOak and JavaEE libraries
>>
>> Hi Stian, do you know what parts of JavaEE Web libraries, LiveOak
>> does not want to use?
>>
>> Right now, I know LiveOak uses Jax-RS and WebSockets.
>>
>> Does it use CDI, Servlets?
>>
>> Regards, Anil _______________________________________________
>> 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
>
2:47 p.m.
On 5/16/2014 8:23 AM, Stan Silvert wrote:
On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
> Yes, the intention is that LiveOak doesn't require JEE container. We
> started with pure netty container. Currently we deploy on WildFly for
> several reasons, also because of KeyCloak. However we want to start
> stripping it down as soon as WildFly Core is available.
I'm working on "Keycloak without servlets" right now. The goal is to be
able to use Keycloak for the EAP console where servlets are verboten.
So far so good.
But it begs the question, "Since the Servlet API is mostly just a facade
on top of the Undertow API, why do we care if Keycloak is using the
Servlet API?"
There's two places we use the servlet API. In KeycloakApplication and
in CookieHelper. The former is to get the context path of the
deployment, the latter is because JAX-RS 1.1 API (required because of
EAP 6.x) doesn't support HttpOnly Cookies.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:08 p.m.
On 5/16/2014 8:47 AM, Bill Burke wrote:
On 5/16/2014 8:23 AM, Stan Silvert wrote:
> On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
>> Yes, the intention is that LiveOak doesn't require JEE container. We
>> started with pure netty container. Currently we deploy on WildFly for
>> several reasons, also because of KeyCloak. However we want to start
>> stripping it down as soon as WildFly Core is available.
> I'm working on "Keycloak without servlets" right now. The goal is to
be
> able to use Keycloak for the EAP console where servlets are verboten.
> So far so good.
>
> But it begs the question, "Since the Servlet API is mostly just a facade
> on top of the Undertow API, why do we care if Keycloak is using the
> Servlet API?"
There's two places we use the servlet API. In KeycloakApplication and
in CookieHelper. The former is to get the context path of the
deployment, the latter is because JAX-RS 1.1 API (required because of
EAP 6.x) doesn't support HttpOnly Cookies.
Also, I see that UndertowUserSessionManagement is using the servlet's
HttpSession class. But it probably should be using Undertow's Session
class instead.
My main point was to ask Boleslaw why it matters. I think the technical
arguments against using the Servlet API have gotten much weaker.
3:43 p.m.
On 5/16/2014 9:08 AM, Stan Silvert wrote:
On 5/16/2014 8:47 AM, Bill Burke wrote:
>
> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>> On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>> started with pure netty container. Currently we deploy on WildFly for
>>> several reasons, also because of KeyCloak. However we want to start
>>> stripping it down as soon as WildFly Core is available.
>> I'm working on "Keycloak without servlets" right now. The goal is
to be
>> able to use Keycloak for the EAP console where servlets are verboten.
>> So far so good.
>>
>> But it begs the question, "Since the Servlet API is mostly just a facade
>> on top of the Undertow API, why do we care if Keycloak is using the
>> Servlet API?"
> There's two places we use the servlet API. In KeycloakApplication and
> in CookieHelper. The former is to get the context path of the
> deployment, the latter is because JAX-RS 1.1 API (required because of
> EAP 6.x) doesn't support HttpOnly Cookies.
>
>
Also, I see that UndertowUserSessionManagement is using the servlet's
HttpSession class. But it probably should be using Undertow's Session
class instead.
My main point was to ask Boleslaw why it matters. I think the technical
arguments against using the Servlet API have gotten much weaker.
I haven't implemented a pure Undertow adapter yet.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:03 p.m.
On 5/16/2014 9:43 AM, Bill Burke wrote:
On 5/16/2014 9:08 AM, Stan Silvert wrote:
> On 5/16/2014 8:47 AM, Bill Burke wrote:
>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>> On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
>>>> Yes, the intention is that LiveOak doesn't require JEE container. We
>>>> started with pure netty container. Currently we deploy on WildFly for
>>>> several reasons, also because of KeyCloak. However we want to start
>>>> stripping it down as soon as WildFly Core is available.
>>> I'm working on "Keycloak without servlets" right now. The goal
is to be
>>> able to use Keycloak for the EAP console where servlets are verboten.
>>> So far so good.
>>>
>>> But it begs the question, "Since the Servlet API is mostly just a
facade
>>> on top of the Undertow API, why do we care if Keycloak is using the
>>> Servlet API?"
>> There's two places we use the servlet API. In KeycloakApplication and
>> in CookieHelper. The former is to get the context path of the
>> deployment, the latter is because JAX-RS 1.1 API (required because of
>> EAP 6.x) doesn't support HttpOnly Cookies.
>>
>>
> Also, I see that UndertowUserSessionManagement is using the servlet's
> HttpSession class. But it probably should be using Undertow's Session
> class instead.
>
> My main point was to ask Boleslaw why it matters. I think the technical
> arguments against using the Servlet API have gotten much weaker.
I haven't implemented a pure Undertow adapter yet.
I'm hacking on one right now, but I'm questioning if it will every
really be needed.
4:28 p.m.
On 05/16/2014 09:03 AM, Stan Silvert wrote:
On 5/16/2014 9:43 AM, Bill Burke wrote:
> On 5/16/2014 9:08 AM, Stan Silvert wrote:
>> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>>> On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
>>>>> Yes, the intention is that LiveOak doesn't require JEE container.
We
>>>>> started with pure netty container. Currently we deploy on WildFly
for
>>>>> several reasons, also because of KeyCloak. However we want to start
>>>>> stripping it down as soon as WildFly Core is available.
>>>> I'm working on "Keycloak without servlets" right now. The
goal is to be
>>>> able to use Keycloak for the EAP console where servlets are verboten.
>>>> So far so good.
>>>>
>>>> But it begs the question, "Since the Servlet API is mostly just a
facade
>>>> on top of the Undertow API, why do we care if Keycloak is using the
>>>> Servlet API?"
>>> There's two places we use the servlet API. In KeycloakApplication and
>>> in CookieHelper. The former is to get the context path of the
>>> deployment, the latter is because JAX-RS 1.1 API (required because of
>>> EAP 6.x) doesn't support HttpOnly Cookies.
>>>
>>>
>> Also, I see that UndertowUserSessionManagement is using the servlet's
>> HttpSession class. But it probably should be using Undertow's Session
>> class instead.
>>
>> My main point was to ask Boleslaw why it matters. I think the technical
>> arguments against using the Servlet API have gotten much weaker.
> I haven't implemented a pure Undertow adapter yet.
>
I'm hacking on one right now, but I'm questioning if it will every
really be needed.
In a REST world, I think a pure http driven approach is better
compared
to relying on the servlet api. You see a lot of applications just
migrating to Netty based handlers rather than web applications. So what
you are trying to do: pure undertow adapter may be quite useful.
You can still use the web application/servlet API for Administration.
But for your REST endpoints, I would go with Undertow + REST framework
or Netty+REST.
5:34 p.m.
On 5/20/2014 10:28 AM, Anil Saldhana wrote:
On 05/16/2014 09:03 AM, Stan Silvert wrote:
> On 5/16/2014 9:43 AM, Bill Burke wrote:
>> On 5/16/2014 9:08 AM, Stan Silvert wrote:
>>> On 5/16/2014 8:47 AM, Bill Burke wrote:
>>>> On 5/16/2014 8:23 AM, Stan Silvert wrote:
>>>>> On 5/16/2014 4:04 AM, Bolesław Dawidowicz wrote:
>>>>>> Yes, the intention is that LiveOak doesn't require JEE
container. We
>>>>>> started with pure netty container. Currently we deploy on WildFly
for
>>>>>> several reasons, also because of KeyCloak. However we want to
start
>>>>>> stripping it down as soon as WildFly Core is available.
>>>>> I'm working on "Keycloak without servlets" right now.
The goal is to be
>>>>> able to use Keycloak for the EAP console where servlets are
verboten.
>>>>> So far so good.
>>>>>
>>>>> But it begs the question, "Since the Servlet API is mostly just
a facade
>>>>> on top of the Undertow API, why do we care if Keycloak is using the
>>>>> Servlet API?"
>>>> There's two places we use the servlet API. In KeycloakApplication
and
>>>> in CookieHelper. The former is to get the context path of the
>>>> deployment, the latter is because JAX-RS 1.1 API (required because of
>>>> EAP 6.x) doesn't support HttpOnly Cookies.
>>>>
>>>>
>>> Also, I see that UndertowUserSessionManagement is using the servlet's
>>> HttpSession class. But it probably should be using Undertow's Session
>>> class instead.
>>>
>>> My main point was to ask Boleslaw why it matters. I think the technical
>>> arguments against using the Servlet API have gotten much weaker.
>> I haven't implemented a pure Undertow adapter yet.
>>
> I'm hacking on one right now, but I'm questioning if it will every
> really be needed.
In a REST world, I think a pure http driven approach is better compared
to relying on the servlet api. You see a lot of applications just
migrating to Netty based handlers rather than web applications. So what
you are trying to do: pure undertow adapter may be quite useful.
You can still use the web application/servlet API for Administration.
But for your REST endpoints, I would go with Undertow + REST framework
or Netty+REST.
I do want to set expectations here. What I am doing now is just a
POC
showing the EAP console using Keycloak. Since this app is not deployed
as a WAR I can not use the servlet API. So right now I'm just filling
in the gaps to make this work in pure Undertow.
It will be awhile before this gets refactored into a pure Undertow
adapter. At that point I'll need some oversight from Bill to make sure
I'm doing it right.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3622
days inactive
3627
days old
9 comments
5 participants
participants (5)
-
Anil Saldhana -
Bill Burke -
Bolesław Dawidowicz -
Stan Silvert -
Stian Thorgersen