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