[wildfly-dev] PicketLink pulling in JPA (Was: Changes to the PicketLink Module)

[Fernando Ribeiro]

Great, will do! Thanks.
On Aug 6, 2013 10:13 PM, "Anil Saldhana" <Anil.Saldhana at redhat.com> wrote:

>  Fernando - you should resolve the ticket as 'wont fix'. 2.1.8 will be
> released soon.
>
> On 08/06/2013 06:39 PM, Fernando Ribeiro wrote:
>
> 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.
>
>
> On Tue, Aug 6, 2013 at 8:30 PM, Anil Saldhana <Anil.Saldhana at redhat.com>wrote:
>
>>  Fernando,
>>   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.
>>
>> Regards,
>> Anil
>>
>>
>> On 08/06/2013 06:22 PM, Fernando Ribeiro wrote:
>>
>> 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.
>>
>>
>> On Tue, Aug 6, 2013 at 8:13 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> The API/SPI you're talking about is higher up the stack, IMO, at least
>>> from the picketlink IDM API.
>>>
>>> On 8/6/2013 6:59 PM, Tomaž Cerar wrote:
>>> > Guys!
>>> >
>>> > I think this discussion has currently no point, as clearly there are
>>> two
>>> > groups of people talking about different things.
>>> >
>>> > Lets take step back and define what is being discussed.
>>> >
>>> > Jason is talking about having some core IDM api/spi part of WildFly so
>>> > we could build on top of it,
>>> > first use case we need this for is Undertow which would use it for
>>> > adding new authentication mechanisms.
>>> >
>>> > What most of others are arguing is how should PL be integrated into
>>> WildFly.
>>> >
>>> > To lay some common grounds here, if we want to put anything into core
>>> > WildFly not as a subsystem it has to have as minimal dependencies as
>>> > possible.
>>> > If that dependency is only JDK that is optimal solution, this is why
>>> > discussion why we dont want to have anything EE-like in WildFly core.
>>> >
>>> > To make it easier to understand, there is long term plan to split
>>> > WildFly core into separete distribution that will be about 10-15mb big
>>> > and will then allow you to install whatever profile you need it to run,
>>> > that might be EE, OSGi, TB, CD or whatever profile or set of extensions
>>> > you will need to run your applications.
>>> >
>>> > This "core" exists already today but it is part of same code base and
>>> > distribution, that is why most people see AS just as whole EE bundle
>>> > that we provide for download.
>>> >
>>> > So what can we do about IDM integration? First we need some core
>>> API/SPI
>>> > that we would like to have as part of WildFly core
>>> > and as add-on to that there should be extension (subsystem) that could
>>> > provide all the advanced stuff users would need.
>>> >
>>> > I don't know PL too much so i dont know if it is possible to have some
>>> > core api/spi and everything else loaded as plugins (maybe via service
>>> > loader)?
>>> > this way user could configure jpa based storage if running in EE
>>> > container otherwise it could be file, memory or direct db based one(i
>>> > have no idea which ones are there)
>>> >
>>> > So what we need as starting point is some as small as possible set of
>>> PL
>>> > (or whatever else we need) that would embedded in core and that could
>>> > communicate fuhrer.
>>> >
>>> >
>>> > --
>>> > tomaz
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ​
>>> >
>>>
>>
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130806/ce2c6fa8/attachment-0001.html