Dennis/Ate,
The credential is not transient. It is persistent and I verified it was
written to the database. The "feature" is that setting a password is
deferred by transient tracking members in PasswordCredentialImpl. With
OBJ, a new credential instance is read from the DB on every access and
that circumvents the set password tracking. With JPA, the objects are
cached. Within the same transaction, you are ensured of getting the same
instance back, even if it has been flushed to the database on a commit.
Because its the same instance, the getPassword() access retrieves the
old value, despite the fact that the credential has in fact been updated.
I do not want to do something that is wrong here. The deferred password
set operation is there for a reason no doubt, but I am wondering if it
is safe to override that capability in this case. Perhaps Ate can
comment on why PasswordCredential does this in general and if it is
appropriate to disable it here?
Randy
Dennis Dam wrote:
Hi Randi,
it's fine by me if you don't have other options. I guess you can't (or don't
want to) force a write-through of the password, and discard the transient
credential?
regards,
Dennis
-----Oorspronkelijk bericht-----
Van: Randy Watler [mailto:wat...@wispertel.net]
Verzonden: ma 9-2-2009 10:41
Aan: Jetspeed Developers List
Onderwerp: SSO PasswordCredential Question
Ate/Dennis,
In SSOManagerImpl.setPassword(), we invoke
PasswordCredential.setPassword(xxx, false) from
TestSSOManager.testCredentials() and then requery the password later in
the test to see if it has changed.
This works fine with OBJ, but with JPA I get the same PasswordCredential
instance back on the requery because it is in an
'Extended'/'Conversational' transaction. As a result, the 'new password
set' transient tracking in PrincipalCredentialImpl is active and is as
if the user just set the password. This means that the
PasswordCredential.getPassword() returns the previous password value and
the test fails.
I am wondering if immediately after the PasswordCredential.setPassword()
call the SSOManagetImpl.setPassword() method should invoke
PasswordCredential.clearNewPasswordSet()? That seems like it might make
sense in this case since we're forcing a password change, no?
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
