Stateless (Flyweight) and current user

Jesus M. Rodriguez jesusr at redhat.com
Thu Apr 1 15:04:02 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/01/2010 10:40 AM, Adam Young wrote:
> The current implementation of candlepin is complete oblivious to the 
> caller.  We can authenticate, but once we do, we do not tailor the 
> output of the calls based on who logged in.
> 
> If we are to implement the multi-org functionality, we need to rpovide a 
> mechanism for checking "who asked this."
> 
> 
> For example, on  ConsumerResource.list is implemented as:
> 
>   public List<Consumer> list() {
>          return consumerCurator.findAll();
>      }
> 
> 
> To filter this via user, we have three choices.  I'm going to use 
> rincipal for the user, as we don't havea first calss user object yet, 
> but we can change that later.
> 
> 1.  Change the method signature
> 
> 
>   public List<Consumer> list(Principal p) {
>          return consumerCurator.findByOwner(getOwner(p));
>      }

At the risk of bringing up what some folks call 'jerl', we used
this approach in spacewalk at the manager layer (i.e. our curators).
Since we didn't want the managers to worry about request level
details like finding the user. So we made it explicit as part of
the method signature.

At first it feels dirty, but it did make it explicit where the
user was being used to filter the data.

> 2.  Add it to the ConsumerResource constructor via dependency injection. 
> (Note that I wouldn't really implement getOwner this way, just to 
> demostrate)
> 
> 
>   public List<Consumer> list() {
>          return 
> consumerCurator.findByOwner(this.getOwner(this.getPrinciapl()));
>      }
> 
> 3.  Fetch it from a context like JNDI
> 
>   public List<Consumer> list() {
>          Principal p = (Principal)new 
> InitialContext().resolve(Principal.class.getName());
>          return consumerCurator.findByOwner(this.getOwner(p));
>      }

I like the idea of a context but *NOT* like the one you described above.

I vote for a combination of *ALL* of the above. In the Resource layer
we have the Context injected into them. Then we lookup the logged in user
from said Context. Then we pass the user down to the Curators.

This allows the resource to use the request context information,
the curators are none the wiser about where the user comes from. It will
make testing the curators easier since you can pass in mock Users. And
the resources can get mock Context objects.

So my vote is for Option 4 :D

jesus

- -- 
jesus m. rodriguez          | jesusr at redhat.com
principal software engineer | irc: zeus
red hat systems management  | 919.754.4413 (w)
rhce # 805008586930012      | 919.623.0080 (c)
+---------------------------------------------+
|   "Those who cannot remember the past       |
|    are condemned to repeat it."             |
|                        -- George Santayana  |
+---------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAku0teEACgkQvJZ57YntiYM8/wCfaTb1USK60A/ekPElXpHVahMO
JOAAoI/sR//I62zq5PVNS8AAVkEm6+Bk
=mFmM
-----END PGP SIGNATURE-----



More information about the candlepin mailing list