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

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?

> 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. wdyt?

Marek