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

[Fernando Ribeiro]

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
>
>


-- 
Fernando Ribeiro
Upic
+55 11 9 8111 4078
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130806/bc8d11a3/attachment-0001.html