[wildfly-dev] PicketLink pulling in JPA (Was: Changes to the PicketLink Module)
Anil Saldhana
Anil.Saldhana at redhat.com
Tue Aug 6 21:10:26 EDT 2013
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 <mailto: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
>> <mailto: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, Tomaz( 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130806/5554227e/attachment.html
More information about the wildfly-dev
mailing list