[security-dev] PicketLink3 and Apache Deltaspike Dependencies

[Pete Muir]

I spoke to Shane on Friday night to discuss an approach to this, where we copy over the DS API classes (which is just a few classes), and then hide the DS impl inside the JBoss module that we package picket link in. This should be acceptable to EAP (it's not public, its just impl detail).

Due to JBoss Modules, we can then load a different version of DS inside the WAR with no problems, off it's class loader.

On 15 Feb 2013, at 17:36, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Pete/Shane,
>   not sure on the exact mechanics. I will defer it to Shane.
> 
> Wondering about the following:
> PL3 core aims to be a portable security extension of Apache Deltaspike. 
> There
> is very little direct dependence on DS. What DS brings is a core CDI 
> enabled runtime.
> 
> So, why not have the following?
> 
> (PL3)  + (PL3/DS Bridge)  =>  EE Applications running on Apache DS on EE 
> containers.
> PL3 => CDI enabled EE Applications running on JBoss AS7+
> 
> Basically this will let PL3 get into an AS release easily since it does 
> not have any dependencies
> on incubating snapshots.
> 
> Now this PL/DS bridge may be a lean DS Security Extension or some minor 
> abstractions.
> 
> Regards,
> Anil
> 
> On 02/15/2013 09:18 AM, Anil Saldhana wrote:
>> I guess we may have to create a leaner Deltaspike security extension.
>> Currently it pulls a lot of core DS classes. We may not need a lot of
>> the crafty stuff
>> that exists in Apache DS Security Extension, just to kick in a Security
>> Interceptor.
>> 
>> On 02/15/2013 09:09 AM, Pete Muir wrote:
>>> I'll try to talk to Shane synchronously, as I think this is possible.
>>> 
>>> On 15 Feb 2013, at 14:54, Anil Saldhana wrote:
>>> 
>>>> I think I brought over more classes than PL core needed. But things were
>>>> broken at runtime.  Shane took a look and said that we will pull more
>>>> core DS classes if we bring the additional security related classes that
>>>> I missed.  So we decided to revert and think of a plan B. :)
>>>> 
>>>> On 02/15/2013 05:49 AM, Pete Muir wrote:
>>>>> Does this commit cover everything, or did you need more?
>>>>> 
>>>>> https://github.com/picketlink/picketlink/commit/2a9d1894dc1e15320d227377c2dd3372651377c0
>>>>> 
>>>>> Particularly the config stuff and project stage stuff I would expect us to be able remove the need for.
>>>>> 
>>>>> On 15 Feb 2013, at 04:34, Jason Porter wrote:
>>>>> 
>>>>>> It may not be the best option, but we should probably stick with v0.3 for now.
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>> On Feb 14, 2013, at 18:31, Anil Saldhana <asaldhan at redhat.com> wrote:
>>>>>> 
>>>>>>> Nothing needed.
>>>>>>> 
>>>>>>> On Feb 14, 2013, at 6:47 PM, Jason Porter <lightguard.jp at gmail.com> wrote:
>>>>>>> 
>>>>>>>> Is there anything in v0.4 you need, or can you simply get by with v0.3
>>>>>>>> 
>>>>>>>> Sent from my iPhone
>>>>>>>> 
>>>>>>>> On Feb 14, 2013, at 17:29, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>>>>>>>> 
>>>>>>>>> Scratch this plan.  Shane and I determined that this is larger than we
>>>>>>>>> originally thought -> lots of DS classes need to be forked.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 02/13/2013 10:25 AM, Anil Saldhana wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>> PicketLink3 is on the final stretch of release cycles.  One of the
>>>>>>>>>> concerns I have had is the Apache Deltaspike dependency which is some
>>>>>>>>>> type of incubating snapshot. Since there are very few Deltaspike classes
>>>>>>>>>> (3-5 in number) that we depend on, the following strategy should work:
>>>>>>>>>> - Copy the source files (Retaining Apache Headers) as it is from Apache
>>>>>>>>>> Deltaspike to a PicketLink namespace such as : org.picketlink.deltaspike.*
>>>>>>>>>> - Remove the Apache Deltaspike dependency.
>>>>>>>>>> 
>>>>>>>>>> In few months, when Apache Deltaspike has proper releases, we can remove
>>>>>>>>>> the PicketLink Deltaspike forked classes and bring back the Apache
>>>>>>>>>> Deltaspike dependency back.  I do not think PicketLink users will
>>>>>>>>>> directly code to DS classes.
>>>>>>>>>> 
>>>>>>>>>> I ran this with Pete Muir, Shane and Jason Porter and they all agreed
>>>>>>>>>> that this is a good strategy (I did refine the strategy based on Shane's
>>>>>>>>>> comments).
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Anil
>>>>>>>>> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev