[security-dev] Dependency of idm/impl on config module

[Anil Saldhana]

On 02/08/2013 12:00 PM, Marek Posolda wrote:
> On 08/02/13 14:31, Shane Bryzak wrote:
>> On 08/02/13 02:00, Marek Posolda wrote:
>>> On 07/02/13 17:01, Shane Bryzak wrote:
>>>> Oops, I didn't mean to commit that before discussing with you, it must
>>>> have snuck in with some other changes that I had to make to help out
>>>> Bruno with one of the Aerogear examples.  In any case, we do need to
>>>> remove the dependency on the config module from idm - I'm ok with a
>>>> dependency going the other way though.
>>> Ok, but why we need to remove it? Is it some xml related conflict? I
>>> have same problem today again. I fixed it locally in my env, but i
>>> won't commit it until we sort this out.
>> The most immediate problem is that it's breaking deployments - the
>> config module is pulling in the federation module, which causes a
>> deployment error in AS just from having the jar file present.
> Hmm... actually the "config" module shouldn't be dependent on
> "federation" module. Few weeks ago it was the case (and maybe you are
> using older version of picketlink in aerogear), but in latest picketlink
> master it's not the case anymore. Currently it should be opposite. In
> other words, "config" module is currently dependent only on "common"
> module and
> both "federation" and "idm" modules are dependent on config module. Or
> am I missing something?
This is correct.
>> Besides that though, the only dependency we should have in idm is on
>> the common module.  Also, configuration should be able to be written
>> as a totally separate concern from IDM - is there a reason that
>> XMLBasedIdentityManagerProvider and all the resolver/* classes can't
>> go in the config module?
> I think that if we want to use XML configuration in IDM unit tests, we
> need to have those XML configuration classes and classes like
> XMLBasedIdentityManagerProvider accessible from idm module. Those XML
> type classes also needs to be accessible from "federation" module.
>
> I think that deployment structure with:
> - "common" module as the base module
> - "config" module dependent only on "common" module
> -  "federation" module dependent on "config" module (and "common" module)
> - "idm" module dependent on "config" module (and "common" module)
>
> seems to me like most natural.
We want to have a single xml configuration file for PicketLink that 
includes IDM and federation settings.
This is the natural way for PicketLink v2 users to migrate to v3.
>
> wdyt?
> Marek
>
>
>>> Thanks,
>>> Marek
>>>> On 07/02/13 05:23, Marek Posolda wrote:
>>>>> Hi Shane,
>>>>>
>>>>> I found today that I am unable to build idm/impl module due to
>>>>> commented
>>>>> dependency on "config" module, which is coming from your commit
>>>>> "e1494891b5f906fb5e54511141ee7d661e4941b9 minor dependency fix" .
>>>>> To fix
>>>>> this, I partially reverted it and uncomment the config module
>>>>> again. See
>>>>> commit
>>>>> https://github.com/mposolda/picketlink/commit/4ff92be99e0ed9ed8898814bdddce19c11520723
>>>>>
>>>>> in PR https://github.com/picketlink/picketlink/pull/50 (It's also
>>>>> adding
>>>>> sorting support in FileBasedIdentityStore).
>>>>>
>>>>> Wdyt? Are you able to build idm/impl without dependency on config
>>>>> module? On my side, I am using "mvn clean install" to build whole
>>>>> project and with commented config module, it's failing for me.
>>>>>
>>>>> Thanks,
>>>>> Marek