portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sami Leino" <sami.le...@netorek.fi>
Subject Extending profile locator in Jetspeed 1
Date Wed, 19 Nov 2003 14:16:54 GMT

Our Intranet package (which is built on top of Jetspeed 1.4-b5) has a
support for multiple organizations (and departments) at the portlet level.
However, the package doesn't offer full support for multiple organizations
at the aggregation level, so we are currently unable to add some features
that we'd like to have. One of them is organization-based PSML fallback

So I would like to ask you if there is an easy way to achieve it? The
fallback order I would like to have is something like this:

1) Try to locate user's personal profile
2) Try to locate profile based on user's organization AND role
3) Try to locate profile based on user's role
4) Get the default profile

I would like to point out that we don't have personal profiles for any
user; every user has a profile based on his/her role. I will describe the
reasons for this later on.

As you see, phase 2 is an addition to Jetspeed profile locator mechanism.
So we could use the organization information found from our customized
user object to find the profile, but the problem is that the user is not
anymore present in the ProfileLocator object during this phase.

Another alternative I considered is to override CastorPSMLManagerService
and make the following kind of "hack" to the subclass:

    protected PSMLDocument getDocument(ProfileLocator locator, boolean
        PSMLDocument doc = getDocumentPrivate(locator, getCached, false);

        if (doc == null && locator.getUser() != null)
            doc = getDocumentPrivate(locator, getCached, true);

        return doc;

    private PSMLDocument getDocumentPrivate(ProfileLocator locator,
boolean getCached, boolean useOrganization)

The hack works when reading the profile in, but saving profile fails,
because Jetspeed thinks that the User has a personal profile.

The correct way would be to extend the ProfileLocator implementation to
contain information about the organization. However, I don't think that
the ProfileLocator implementation can be configured, can it? Additionally,
ProfileLocator instance is manipulated in some many places that modifying
it would required us to change very many classes indeed? Am I correct?

ProfileLocator contains support for Groups. We could use Group to
represent organization, but since Jetspeed uses Group for it's own
purposes, this doesn't seem to be a good alternative either.

You will of course ask why we use roll-based fallback for profiles. The
reason for this is that we have five different roles, and there are dozens
or hundreds of users in every role category; we don't want each of them to
have their personal profile. Since the end users cannot manage their
profiles themselves, having a profile for each individual user is really 
unnecessary for us and would make the portal hard to administrate. Our
next deployment will have to support over 3000 users and having over 3000
individual profiles is something we definitely don't want.

One alternative could - of course - be to define separate roles for
different organizations. There could be "org1-user" and "org2-user" and so
on, but this would make the access control more complicated. The preferred
solution would be to extend the ProfileLocator is possible, but I wouldn't
want to directly replace the Jetspeed classes if I could use subclassing.

Any ideas?




Sami Leino
Software Developer
Netorek Oy

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message