<p dir="ltr">Great, will do! Thanks.</p>
<div class="gmail_quote">On Aug 6, 2013 10:13 PM, "Anil Saldhana" <<a href="mailto:Anil.Saldhana@redhat.com">Anil.Saldhana@redhat.com</a>> wrote:<br type="attribution"><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 - 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 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 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><br>
<br>
On 08/06/2013 06:22 PM, Fernando Ribeiro wrote:<br>
</div>
</div>
</div>
<div>
<div>
<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 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>
</div>
<br>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br></blockquote></div>