You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Sami Leino <sa...@netorek.fi> on 2003/11/19 15:16:54 UTC
Extending profile locator in Jetspeed 1
Hi.
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
mechanism.
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
getCached)
{
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?
Regards,
Sami
--
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
Localization question
Posted by Yayati Kasralikar <ya...@indent.org>.
Hello:
We are using JSP and currently are only interested in internationalizing
static text. Out approach is to use JSP to replace the static text using
resource bundles.
We have created properties files and put them in our jar file as
com.a.jetspeed.modules.localization.Message_en_US.properties
com.a.jetspeed.modules.localization.Message_de_DE.properties
We added to turbineresources.properties
locale.default.bundles=com.a.jetspeed.modules.localization.Message,org.apach
e.jetspeed.modules.localization.JetspeedLocalization
We could not get JSP page to work with:
messages = ResourceBundle.getBundle("Message",Locale.GERMANY);
Error we get something like MissingREsourceException.
We got it to work when we did
messages =
ResourceBundle.getBundle("com.a.jetspeed.modules.localization.Message",Local
e.GERMANY);
Question 1: How do we configure turbineresources.properties file so that we
do not have to specify com.a.jetspeed.modules.localization. each time.
Question 2: In this process, we made changes to properties file and the
title which was specified in top.vm now appears as "TOP_TITLE" and the top
righthand section appeares capitalized, prefixed with TOP_ . How do we get
the original top disply back?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Extending profile locator in Jetspeed 1
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Thursday, November 20, 2003, at 02:56 AM, Sami Leino wrote:
>> The Profiler interface already has createProfileLocator() method.
>> Just need to make it configurable via the properties file and load
>> your
>> locator I can make this change easily if you. I will do it today
>
> That would be a nice thing to have. If you have some spare time and see
> this feature useful, please go ahead. Just make sure that the
> implementation defaults to the standard ProfileLocator when the custom
> class has not been excplicitly defined in the property file.
>
Done, do a CVS update to get the changes
>> Jetspeed doesn't actually use Groups for its own purpose, it just
>> always defaults the group to "Jetspeed".
>> I think you could use the Group as the organization.
>> I know that Santiago does this....
>
> I have many times been wondering about the significance of the Group
> entity. Isn't it so that the roles are dependent of the groups in the
> way
> that (in theory) user could have role "admin" within group "group1" and
> role "user" within group "group2"?
Its the security implementation that hard-codes the Jetspeed group
We still use the Turbine database model, although all the Turbine
security has been ripped out
Look at the TURBINE_USER_GROUP_ROLE table
This is the security service represents a user having a role
Its three-way relationship USER + GROUP + ROLE
I think it would be possible to add security checks with the group,
requiring a new set of methods on the RoleManagement interface that
include a group parameter
>
> At least the LDAP implementation ties roles to groups in that way.
> Therefore, I can not totally discard the Jetspeed group, but I could
> attach another group to users for representing the organization. When
> setting the group to ProfileLocator, I could ignore the "Jetspeed"
> group
> and set the other one to it instead. Then, I could use that
> information to
> locate the profile. Do you see this as a good alternative?
>
Yes I think its worth looking into
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Extending profile locator in Jetspeed 1
Posted by Sami Leino <sa...@netorek.fi>.
> The Profiler interface already has createProfileLocator() method.
> Just need to make it configurable via the properties file and load your
> locator I can make this change easily if you. I will do it today
That would be a nice thing to have. If you have some spare time and see
this feature useful, please go ahead. Just make sure that the
implementation defaults to the standard ProfileLocator when the custom
class has not been excplicitly defined in the property file.
> Jetspeed doesn't actually use Groups for its own purpose, it just
> always defaults the group to "Jetspeed".
> I think you could use the Group as the organization.
> I know that Santiago does this....
I have many times been wondering about the significance of the Group
entity. Isn't it so that the roles are dependent of the groups in the way
that (in theory) user could have role "admin" within group "group1" and
role "user" within group "group2"?
At least the LDAP implementation ties roles to groups in that way.
Therefore, I can not totally discard the Jetspeed group, but I could
attach another group to users for representing the organization. When
setting the group to ProfileLocator, I could ignore the "Jetspeed" group
and set the other one to it instead. Then, I could use that information to
locate the profile. Do you see this as a good alternative?
Sami
--
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
Re: Extending profile locator in Jetspeed 1
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Wednesday, November 19, 2003, at 06:16 AM, Sami Leino wrote:
> Hi.
>
> 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
> mechanism.
>
> 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
> getCached)
> {
> 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?
>
Yes it can.
The Profiler interface already has createProfileLocator() method.
Just need to make it configurable via the properties file and load your
locator
I can make this change easily if you. I will do it today
As long as you extend the interface, everything will work as is
> 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.
Jetspeed doesn't actually use Groups for its own purpose, it just
always defaults the group to "Jetspeed".
I think you could use the Group as the organization.
I know that Santiago does this....
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
+44 (0)79 8538 6471
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org