Announcement

Collapse
No announcement yet.

Is there any equivalent to UserReloader in OX 7.4.1?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there any equivalent to UserReloader in OX 7.4.1?

    Hi,
    I'm trying to update some backend OSGI bundles, written for OXSE 6.20.7, to the latest OX 7.4.1 backend.
    One of those bundle leverages on the ability of OX to automatically reload the com.openexchange.groupware.ldap.User in-session object instance when some attributes are changed (eg: through an RMI call).


    Within OXSE 6.20 this was accomplished by using com.openexchange.groupware.ldap.UserReloader
    Code:
    /**
     * This class is used overall behind the User interface and it manages to reload
     * the user object into the cache if the cache invalidated it.
     * @author <a href="mailto:marcus@open-xchange.org">Marcus Klein</a>
     */
    final class UserReloader extends Refresher<User> implements User {
    
        /**
         * For serialization.
         */
        private static final long serialVersionUID = -2424522083743916869L;
    
        /**
         * Cached delegate.
         */
        private User delegate;
    
        ...
    }

    This class in no longer present in OX 7.4.1, so my OSGI bundle does not work as expected because the in-session User object is no longer auto-updated when an RMI update occurs.

    Is this feature no longer supported in OX 7.4.1?

  • #2
    Update: after revising some OX source code, I come to the conclusion that it's no longer possible to update some User attributes and see those changes applyed in session without requiring the user to re-login...

    For example, take a look at com.openexchange.user.UserService#updateUser
    Code:
        /**
         * This method updates some values of a user. In the given user object just set the user identifier and the attributes you want to
         * change. Every attribute with value <code>null</code> will not be touched.
         * <p>
         * Currently supported values for update:
         * <ul>
         * <li>Time zone</li>
         * <li>Language</li>
         * <li>IMAP server</li>
         * <li>SMTP server</li>
         * <li>IMAP login</li>
         * <li>Attributes (if present, not <code>null</code>)</li>
         * </ul>
         * @param user user object with the updated values.
         * @param context The context.
         * @throws OXException  if an error occurs.
         * @see #getContext(int)
         */
        void updateUser(User user, Context context) throws OXException;

    This method in invoked, for example, by com.openexchange.report.internal.LastLoginRecorder #updateLastLogin
    Code:
        /**
         * Updates the last-accessed time stamp for given user's client.
         * @param userService UserService to update the user attributes.
         * @param client The client identifier
         * @param origUser The associated user
         * @param context The context
         * @throws OXException If update fails for any reason
         */
        static void updateLastLogin(UserService userService, String client, User origUser, Context context) throws OXException {
            if (context.isReadOnly()) {
                return;
            }
            // Set attribute
            final Map<String, Set<String>> attributes = new HashMap<String, Set<String>>(origUser.getAttributes());
            // Add current time stamp
            attributes.put("client:" + client, new HashSet<String>(Arrays.asList(Long.toString(System.currentTimeMillis()))));
            final UserImpl newUser = new UserImpl();
            newUser.setId(origUser.getId());
            newUser.setAttributes(attributes);
            try {
                userService.updateUser(newUser, context);
            } catch (final OXException e) {
                throw e;
            }
        }

    This method is called when a user performs a login into OX and, of course, it should update a UserAttribute named "client" with the last-access timestamp.

    Well, I've run OX in remote debug mode in order to inspect all objects and I've found that this method correctly updates the UserAttribute into database, but the original "origUser" object that is put into Session is untouched by this change....


    For example, consider the origUser object with a source UserAttribute as below:
    Code:
    client:com.openexchange.ox.gui.dhtml=[1387370000000]
    This value is the initial value that is stored both in Session and in Database.
    Now, when the updateLastLogin is called, suppose that the new value for this UserAttribute is:
    Code:
    client:com.openexchange.ox.gui.dhtml=[1387379999999]
    This new value is correctly saved into Database, but the "origUser" object put in Session is not updated with this value...


    The problem is that the "origUser" instance is a UserImpl object, and this object has lost the ability to autoreload itself when a cache update occurs (previoulsy, with OXSE 6.20, "origUser" was an instance of UserReloader which in turn wraps the UserImpl instance adding the ability to do "the magic").



    So, at the end of all this "explanation", do you confirm that there is no way to update both database and session User Attributes without requiring the user to re-login into OX?

    Comment


    • #3
      Hi,

      first please do not use com.openexchange.groupware.ldap.UserReloader class to reload a User object even within the session object instance because this is an internal implementation and not designed to work as an API. The behavior of these classes and methods can change with every release and even with a patch.

      Instead of the above you may use the OSGi service com.openexchange.user.UserService. This service can be retrieved in an OSGi manner through the OSGi service registries and service trackers. This interface provides methods to change user data like UserService.updateUser(User, Context) - and to invalidate cached user objects - UserService.invalidateUser(Context, int) as you already mentioned in your posts.

      Unfortunately it seems that you hit a bug in our software here which is now going to be evaluated by our development team and tracked internally via our bug tracking system.

      Thanks for your observations on this & kind Regards
      Thomas

      Comment

      Working...
      X