Stateless (Flyweight) and current user

Adam Young ayoung at redhat.com
Thu Apr 1 14:40:19 UTC 2010


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));
     }


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));
     }



Option 1 is best for cases where this is going to be only required for 
one or two methods.  THe Principal will be needed for just about every 
method.

Option 2 means that the Resource Objects will no longer be stateless, 
but instead will have to be created either on each request, or once per 
session

Option 3 menas we have non-explicit dependencies.


Do we need a meeting for this?








More information about the candlepin mailing list