com.waveset.provision
Class ThreadContext

java.lang.Object
  extended bycom.waveset.provision.ThreadContext
Direct Known Subclasses:
FetchContext, ProvisionContext

public abstract class ThreadContext
extends java.lang.Object

A base class that provides context for one or more ProvisioningThread threads used to perform parallel resource operations. There are two subclasses, FetchContext used to fetch accounts, and ProvisionContext used to modify accounts.


Field Summary
static java.lang.String code_id
           
protected static Trace trace
           
 
Constructor Summary
ThreadContext(Provisioner p, ProvisioningOptions options)
           
 
Method Summary
static WSUser buildResourceUser(WSUser master, ResourceInfo info, java.util.Map changes)
          Build a filtered WSUser object for this resource op.
static boolean buildResourceUser(WSUser master, ResourceOp op, ProvisioningOptions options)
          Build a filtered WSUser object for this resource op.
 void checkAdapters()
          Walk over the ops list resolving references to ResourceAdapters that handle the requests.
 void generateIdentities(java.util.List ops, boolean tolerateFailure)
          Go through the ResourceOps looking for accounts that do not yet have identities and try to create them.
 java.lang.String getAdministratorName()
           
abstract  int getDesiredThreads()
          Get what this context believes to be the ideal number of threads necessary to process the request.
 java.lang.String getExplicitIdentity(ResourceInfo info)
          Given a ResourceInfo that either does not have an accountId check to see if the identity was passed down in the attributes map.
abstract  ResourceOp getNextOp()
          Return the next operation that a thread can perform.
 ResourceOp getOp(ResourceInfo info)
          Get the op that matches the specified ResourceInfo.
abstract  java.util.List getOps()
          Return the list of ResourceOps.
 ProvisioningOptions getOptions()
           
 Provisioner getProvisioner()
           
 WSUser getUser()
           
 java.lang.String getUserName()
           
abstract  boolean isFinished(int thread)
          Returns true once all operations have been performed.
 void launchThreads()
          Launch threads to handle the operations in the context.
 void normalizeResourceInfos()
          Normalize the ResourceInfo list to ensure that there is one for every assigned resource.
 void overrideResourceAttributes()
          Walk over the ops list looking for Resources that need to have overridden resource attributes.
abstract  void prepare()
          Do any last minute preparations before launching threads.
static void println(java.lang.String msg)
           
abstract  void processOp(ResourceOp op, int thread)
          Called by each thread after it has obtained an operation to perform.
 void setTrace(boolean t)
           
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

code_id

public static final java.lang.String code_id
See Also:
Constant Field Values

trace

protected static final Trace trace
Constructor Detail

ThreadContext

public ThreadContext(Provisioner p,
                     ProvisioningOptions options)
Method Detail

setTrace

public void setTrace(boolean t)

println

public static void println(java.lang.String msg)

getOps

public abstract java.util.List getOps()
Return the list of ResourceOps. Used internally by some of the utility methods.


prepare

public abstract void prepare()
                      throws WavesetException
Do any last minute preparations before launching threads.

Throws:
WavesetException

getDesiredThreads

public abstract int getDesiredThreads()
Get what this context believes to be the ideal number of threads necessary to process the request.


isFinished

public abstract boolean isFinished(int thread)
Returns true once all operations have been performed. This is a signal to the thread that it can terminate.

The thread number is passed here so we can selectively decide to let threads expire even though we're not really done with processing. This might happen if we launched 10 threads to do a bunch of random things in parallel, but we're now down to 2 that have to iterate through 2 ordered lists. Since the other threads have nothing to do, we can let them die.


getNextOp

public abstract ResourceOp getNextOp()
Return the next operation that a thread can perform. This needs to be synchronized since it will be called by multiple threads. If null is returned, that doesn't necessarily mean we're finished, we may be waititng for dependent operations to finish.

Note that the implementation of this method must be synchronized.


processOp

public abstract void processOp(ResourceOp op,
                               int thread)
                        throws WavesetException
Called by each thread after it has obtained an operation to perform. This method must not be synchronized, all the state we need should be in the provided ResourceOp.

Throws:
WavesetException

getOptions

public ProvisioningOptions getOptions()

getUser

public WSUser getUser()

getAdministratorName

public java.lang.String getAdministratorName()

getUserName

public java.lang.String getUserName()

getProvisioner

public Provisioner getProvisioner()

launchThreads

public void launchThreads()
                   throws WavesetException
Launch threads to handle the operations in the context. If we determine that we're only allowed to have a single thread, don't launch any, just handle the operations sequentially in the current thread.

Throws:
WavesetException

normalizeResourceInfos

public void normalizeResourceInfos()
                            throws WavesetException
Normalize the ResourceInfo list to ensure that there is one for every assigned resource. Also remove any objects associated with Resources that no longer exist.

Throws:
WavesetException

getExplicitIdentity

public java.lang.String getExplicitIdentity(ResourceInfo info)
Given a ResourceInfo that either does not have an accountId check to see if the identity was passed down in the attributes map. We have historically used "accountId" to convey this but that can conflict with an accountId in the schema map or identity template which is then not the full identity. Now, we only recognize "ws_identity". The user view handler still dances around recognizing "accountId" for temporary compatibility.


generateIdentities

public void generateIdentities(java.util.List ops,
                               boolean tolerateFailure)
                        throws WavesetException
Go through the ResourceOps looking for accounts that do not yet have identities and try to create them. Not all identities may be created if insufficient attributes are available for the identity template, or if the result of the generation is not unique for accounts on the user. Flag controls whether we consider missing identities an exception. This is currently false when fetching to do a best effort for the available accounts. It is true when provisioning under the assumption that you'd prefer all or nothing, though that's debatable.

Throws:
WavesetException

overrideResourceAttributes

public void overrideResourceAttributes()
                                throws WavesetException
Walk over the ops list looking for Resources that need to have overridden resource attributes. Note that this may replace the Resource object in the ResourceOp so you will need to call checkAdapters afterwards.

Throws:
WavesetException

checkAdapters

public void checkAdapters()
                   throws WavesetException
Walk over the ops list resolving references to ResourceAdapters that handle the requests. Note that this must be done after any modifications to the Resource object within the ResourceOp.

Throws:
WavesetException

buildResourceUser

public static boolean buildResourceUser(WSUser master,
                                        ResourceOp op,
                                        ProvisioningOptions options)
                                 throws WavesetException
Build a filtered WSUser object for this resource op. The filtered user contains only the attributes that are of interest to this resource, and ordinarilly will contain only those attributes that have changed. Return true if an update OP can be removed because there are no effective changes to propagate to the resource.

We expect the ResourceInfo to have a non-null map of modified attributes, put there by the user view handler.

We also detect changes to resource attribute overrides stored in the ResourceInfo. When this happens, a custom Resource object will have been created and stored in the op. Differences are indicated by a special resource attribute. NOTE WELL: accountId sucks We have grown with a number of assumptions about the attribute accountId that makes supporting multiple accounts on a resource difficult. accountId often appears in the identity template, and less often in the schema map. When it is in the id template but not the map, we need to be able to pass an accountId down that is not necessarily the same as the Lighthouse accountId. This is ok except that there is code that assumes they are the same: auditing, self-edit detection, possibly recon. Further, once an account has been created, change detection won't send down a change for accountId since it is rarely changed. But code expects there to be a non-null accountId in the WSUser so we have to set it to the Lighthouse accountId. Then the problem is that since accountId appears in the WSUser, it may be treated as a change by the resources if it is in the schema map. This effectively wipes out the accountId on the next edit. We've decided it is reasonable to keep accountId out of the schema map and not treat it as an editable attribute, but that has other consequences that must be carefully considered. Until then, we require that the original accountId attribute be sent down in the ResourceInfo object. I decided to keep it out of the change map to avoid it showing up as a diff in the account tables. Made static for IDMX

Throws:
WavesetException

buildResourceUser

public static WSUser buildResourceUser(WSUser master,
                                       ResourceInfo info,
                                       java.util.Map changes)
                                throws WavesetException
Build a filtered WSUser object for this resource op. The filtered user contains only the attributes that are of interest to this resource, and ordinarilly will contain only those attributes that have changed. Return true if an update OP can be removed because there are no effective changes to propagate to the resource.

We expect the ResourceInfo to have a non-null map of modified attributes, put there by the user view handler.

We also detect changes to resource attribute overrides stored in the ResourceInfo. When this happens, a custom Resource object will have been created and stored in the op. Differences are indicated by a special resource attribute. NOTE WELL: accountId sucks We have grown with a number of assumptions about the attribute accountId that makes supporting multiple accounts on a resource difficult. accountId often appears in the identity template, and less often in the schema map. When it is in the id template but not the map, we need to be able to pass an accountId down that is not necessarily the same as the Lighthouse accountId. This is ok except that there is code that assumes they are the same: auditing, self-edit detection, possibly recon. Further, once an account has been created, change detection won't send down a change for accountId since it is rarely changed. But code expects there to be a non-null accountId in the WSUser so we have to set it to the Lighthouse accountId. Then the problem is that since accountId appears in the WSUser, it may be treated as a change by the resources if it is in the schema map. This effectively wipes out the accountId on the next edit. We've decided it is reasonable to keep accountId out of the schema map and not treat it as an editable attribute, but that has other consequences that must be carefully considered. Until then, we require that the original accountId attribute be sent down in the ResourceInfo object. I decided to keep it out of the change map to avoid it showing up as a diff in the account tables.

Throws:
WavesetException

getOp

public ResourceOp getOp(ResourceInfo info)
Get the op that matches the specified ResourceInfo.