[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