You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Nikolaos Athanasis <at...@ics.forth.gr> on 2003/11/17 22:24:14 UTC
Architecture of jetspeed
Hi all.
Although i am working with jetspeed almost one year, i have some questions
according to the way jetspeed, turbine and the application server
communicate each other.
I try to understand from the page:
http://jakarta.apache.org/jetspeed/site/application-development.html
I have a very simple scenario: A user browses to the URL:
http://server:8080/jetspeed/index.jsp
At what time (ie in which framgment of code) does the application server
communicates with turbine? For example, how is jakarta tomcat communicates
with turbine to send him the http request?
And then, after turbine hanldes the request, at wich time does it invoke
the portlet API?
Is there any pictures wich describes all these complecated things?
Any help would be appreciated...
Nikos.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-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
Extending profile locator in Jetspeed 1
Posted by Sami Leino <sa...@netorek.fi>.
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
Portlets Discussion Group and BLOG
Posted by Punit Pandey <pa...@hotmail.com>.
Hello Friends,
I have created a discussion group and a blog related to portlets
development. Take a little time to visit them. As it is not vendor specific,
we can discuss a lot of thing that can not be discussed at other forums.
Group URL: http://www.yahoogroups.com/group/portlets
Blog URL: http://portlets.blogspot.com
I hope that would be useful.
Regards,
Punit Pandey
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Architecture of jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Tuesday, November 18, 2003, at 10:50 AM, Tod Thomas wrote:
> David,
>
> Will this architecture persist in Jetspeed 2? Judging from discussions
> I've read on this list I believe it won't. If not, could you describe
> the
> differences using the same format as you did below?
>
J2 doesn't rely on Turbine.
J2 has its own servlet.
However J2 has a pipeline architecture, and does not use modules.
The request runs thru the pipeline where different Jetspeed portal
components can plug in to the pipeline and perform some kind of
processing.
http://cvs.apache.org/viewcvs/jakarta-jetspeed-2/portal/src/webapp/WEB-
INF/conf/jetspeed-pipeline.xml?rev=1.3&content-type=text/vnd.viewcvs-
markup
Probably the most significant changes in J2 are:
1. compliant with the Java Portlet Spec
2. Separates Portlet applications from the portal
#2 is very important to the architecture, since we are separating the
concerns of the portal and the portlet application, cleaning up the
system architecture significantly
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Architecture of jetspeed
Posted by Tod Thomas <tt...@chubb.com>.
David,
Will this architecture persist in Jetspeed 2? Judging from discussions
I've read on this list I believe it won't. If not, could you describe the
differences using the same format as you did below?
Thanks.
David Sean Taylor wrote:
> On Monday, November 17, 2003, at 09:24 PM, Nikolaos Athanasis wrote:
>
> > Hi all.
> >
> > Although i am working with jetspeed almost one year, i have some
> > questions
> > according to the way jetspeed, turbine and the application server
> > communicate each other.
> > I try to understand from the page:
> > http://jakarta.apache.org/jetspeed/site/application-development.html
> >
> > I have a very simple scenario: A user browses to the URL:
> > http://server:8080/jetspeed/index.jsp
> >
> > At what time (ie in which framgment of code) does the application
> > server
> > communicates with turbine? For example, how is jakarta tomcat
> > communicates
> > with turbine to send him the http request?
> > And then, after turbine hanldes the request, at wich time does it
> > invoke
> > the portlet API?
> >
> Turbine is a servlet.
> The Turbine servlet class, configured in the web.xml, is called for
> each servlet request.
> Turbine uses modules to generate the servlet response, and Jetspeed
> ties into the module architecture.
> Recommend looking at the Turbine documentation.
>
> http://jakarta.apache.org/turbine/turbine-2.3/fsd.html
>
> Start by looking at the default modules (layouts, screens,
> navigations), all configured in the TurbineResources.properties
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Architecture of jetspeed
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Monday, November 17, 2003, at 09:24 PM, Nikolaos Athanasis wrote:
> Hi all.
>
> Although i am working with jetspeed almost one year, i have some
> questions
> according to the way jetspeed, turbine and the application server
> communicate each other.
> I try to understand from the page:
> http://jakarta.apache.org/jetspeed/site/application-development.html
>
> I have a very simple scenario: A user browses to the URL:
> http://server:8080/jetspeed/index.jsp
>
> At what time (ie in which framgment of code) does the application
> server
> communicates with turbine? For example, how is jakarta tomcat
> communicates
> with turbine to send him the http request?
> And then, after turbine hanldes the request, at wich time does it
> invoke
> the portlet API?
>
Turbine is a servlet.
The Turbine servlet class, configured in the web.xml, is called for
each servlet request.
Turbine uses modules to generate the servlet response, and Jetspeed
ties into the module architecture.
Recommend looking at the Turbine documentation.
http://jakarta.apache.org/turbine/turbine-2.3/fsd.html
Start by looking at the default modules (layouts, screens,
navigations), all configured in the TurbineResources.properties
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org