Ok, I'm going to be working with Emanuel to get the admin edits pushed
into the profile deployments next week, so we'll see
what comes up. I expect the profile service could/should be using an
AttachmentsImpl that does preclude any further setting of
the predetermined value once set?
Adrian Brock wrote:
The second part would be a major change.
Each deployer would have to pass some id as it creates/modifies
attachments.
That is unless we hacked it such that the DeployerWrapper sets
a thread local for the AttachmentsImpl to look at?
Even then, unless we changed the Attachments spi,
there's no guarantee AttachmentsImpl gets used.
e.g. the predetermined stuff gets populated from the Deployment
passed to client api of the deployers.
But in general, the deployers should not be putting
anything in predetermined anyway. It defeats the point
and may not even be allowed with some implementations of
Attachments. ;-)
When I say I'm going to show which deployers process which
deployments, its basically going to be a re-calculation
of what gets done in DeployersImpl::isRelevant()
from the attachments/components that exist at the end of the deployment
processing.
On Fri, 2008-10-03 at 08:34 -0700, Scott Stark wrote:
> Another runtime view is what the source of an attachment is involved
> in the chain:
>
> PredeterminedManagedObjects
> TransientManagedObjects
> TransientAttachments
>
> and ideally which deployer set the current attachment at each level.
> This relates to tracking whether the correct
> attachment is being used when the profile service sets a
> PredeterminedManagedObject.
>
>