<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Fernando - you should resolve the
ticket as 'wont fix'. 2.1.8 will be released soon.<br>
<br>
On 08/06/2013 06:39 PM, Fernando Ribeiro wrote:<br>
</div>
<blockquote
cite="mid:CAKcyLkhq5yBD+Rn6aKNnbocUVDCS_MS=_jbUeLEj670eTXt7eQ@mail.gmail.com"
type="cite">
<div dir="ltr">Definitely right, just wondered if we didn't want
to apply the changes as a temporary fix until 2.1.8 is released,
do you prefer me to just go ahead and resolve the ticket?
Regards.<br>
</div>
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">On Tue, Aug 6, 2013 at 8:30 PM, Anil
Saldhana <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Anil.Saldhana@redhat.com" target="_blank">Anil.Saldhana@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Fernando,<br>
if you use the JDBC based registry, I do not see any
module changes. Do you? If somebody is bent on using
JPA registry, then they can do the necessary changes via
documentation/wiki article.<br>
<br>
Regards,<br>
Anil
<div>
<div class="h5"><br>
<br>
On 08/06/2013 06:22 PM, Fernando Ribeiro wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">Definitely two issues here, but the
first one, related to the JPA-based token
registries, has really already been addressed. The
only missing point is a decision regarding the WF
ticket for the module change. Regards.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Aug 6, 2013 at
8:13 PM, Bill Burke <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bburke@redhat.com"
target="_blank">bburke@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">The API/SPI you're
talking about is higher up the stack, IMO, at
least<br>
from the picketlink IDM API.<br>
<div>
<div><br>
On 8/6/2013 6:59 PM, Tomaž Cerar wrote:<br>
> Guys!<br>
><br>
> I think this discussion has currently
no point, as clearly there are two<br>
> groups of people talking about
different things.<br>
><br>
> Lets take step back and define what
is being discussed.<br>
><br>
> Jason is talking about having some
core IDM api/spi part of WildFly so<br>
> we could build on top of it,<br>
> first use case we need this for is
Undertow which would use it for<br>
> adding new authentication mechanisms.<br>
><br>
> What most of others are arguing is
how should PL be integrated into WildFly.<br>
><br>
> To lay some common grounds here, if
we want to put anything into core<br>
> WildFly not as a subsystem it has to
have as minimal dependencies as<br>
> possible.<br>
> If that dependency is only JDK that
is optimal solution, this is why<br>
> discussion why we dont want to have
anything EE-like in WildFly core.<br>
><br>
> To make it easier to understand,
there is long term plan to split<br>
> WildFly core into separete
distribution that will be about 10-15mb
big<br>
> and will then allow you to install
whatever profile you need it to run,<br>
> that might be EE, OSGi, TB, CD or
whatever profile or set of extensions<br>
> you will need to run your
applications.<br>
><br>
> This "core" exists already today but
it is part of same code base and<br>
> distribution, that is why most people
see AS just as whole EE bundle<br>
> that we provide for download.<br>
><br>
> So what can we do about IDM
integration? First we need some core
API/SPI<br>
> that we would like to have as part of
WildFly core<br>
> and as add-on to that there should be
extension (subsystem) that could<br>
> provide all the advanced stuff users
would need.<br>
><br>
> I don't know PL too much so i dont
know if it is possible to have some<br>
> core api/spi and everything else
loaded as plugins (maybe via service<br>
> loader)?<br>
> this way user could configure jpa
based storage if running in EE<br>
> container otherwise it could be file,
memory or direct db based one(i<br>
> have no idea which ones are there)<br>
><br>
> So what we need as starting point is
some as small as possible set of PL<br>
> (or whatever else we need) that would
embedded in core and that could<br>
> communicate fuhrer.<br>
><br>
><br>
> --<br>
> tomaz<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> ​<br>
><br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>