Hi Dominik,
You should not populate attributes in this manner, for the very reason you're experiencing. Attributes are transient adn behave like variables, i.e. when the class stops existing they disappear. During binding only the key is transferred, and - if needed - the class is re-instantiated at the other end. If you have implemented some kind of buffering/instance management (not a bad idea), then you may be lucky to have attributes survive if everything happens within the same program context. However once your WF session stops executing, this is lost.
This is why when you look at the log later, it is re-instantiating a completely new instance - where would it know the approver from?
The attribute value must be written to the DB somewhere, so that any later object instantiation (e.g. when you look at the log) will read the value and populate the attributes correctly.
Incidentally this is why OO theory discourages the use of public attributes and suggests GET_ and SET_ methods instead....
Regards,
Mike
