portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: portlet entity Editor
Date Sun, 04 Nov 2007 01:18:11 GMT

On Nov 3, 2007, at 2:50 AM, Mansour wrote:

>> No need to get on your high horse about standards with me. I know  
>> PSML is not a standard, and I know JSP is a "Java standard".
> I did not mean to do this. I am sorry that you took it this way.
>> That line of thinking is in line with my thinking here: why are  
>> you messing around with portlet entities and the Jetspeed  
>> implementation.
>> You should be implementing this code as a part of your business  
>> logic, your portlet application, not with Jetspeed-specific impl  
>> details (Entity Manager) in the portal.
>>  I still see no reason for you to be meddling with the portal  
>> implementation layer, when you should be sticking to standards,  
>> and using the Portlet API to handle this, in your application code
>> I believe the portlet api gives you the interfaces you need to  
>> accomplish your use case
> From my understanding, jetspeed can be used to manage the security  
> and permissions. I did not know that I should handle this in my  
> business logic. I though the businees logic is only for business  
> logic, and the portal should help me separate the concerns by  
> handling the permissions and access to the resources.

I agree with what you are saying there, your business logic shouldn't  
be configuring security, thats the role of the portal as that follows  
the separation of concerns pattern

>> Let me give it a try.
>> Using strictly the portlet api, it doesn't have a concept of groups.
>> Im not sure how many groups you have, by why not have the  
>> administrator go into edit-defaults mode, and configure the  
>> portlets with the following preferences:
> that's exactly what I need. The top level (portal) administrator  
> configures this connection strings. in other words, the top level  
> administrator, creates as many instances as she needs. An instance  
> for each client. Each client has an admin on site. The site admin  
> can give permissions for the users (depending on their job) to view  
> or modify the config. No user or admin can change the connection  
> string. The users can choose to add the entity to the portlet  
> entity to their page.

I think this is a good case for "default" preferences. Remember you  
can have 3 kinds of preferences:

1. "global" default preferences per portlet configured in the  
2. Default preferences per page configured on the portlet page in  
"edit_defaults" mode
3.  the user can have user-specific preferences per portlet on a page.
      this implies that you can have two of the same portlets  on the  
same page with different default preferences, as well as different  
prefs per user

So say we have a portlet named ReportPortlet with prefs named  
"connectionString", "userName", "password"
In the portlet.xml, we configure the global settings to:


and then the admin  goes into edit defaults mode, and overrides the  
connection to for a ReportPortlet placed on a page named  


and then the admin  goes into edit defaults mode, and overrides the  
connection to for a ReportPortlet placed on a page named  


and so on...
The one draw back here is that you will need to set the security  
constraints on the "fragments", or portlet instances, by hand in PSML  
We are working on a administrative "configure" mode though for 2.1.3  
to edit fragment constraints....
I guess one way to get around that limit in 2.1.2 is to have one  
ReportPortlet per client configured in the jetspeed-portlet.xml with:


After all that, I may still prefer the SSO solution

>> groupA-connection = jdbc:mysql://server1/schema1
>> groupB-connection = jdbc:mysql://server2/schema2
>> groupC-connection = jdbc:mysql://server2:schema3
> does this mean this can be done without programming the security  
> and permissions?

I think so, see above

>> and so forth
>> then in your portlet, lookup the preference based upon what group  
>> the user is in. Of course there is no standard way to do that in  
>> the portlet api short of getting the Subject in a Jetspeed  
>> specific way
>> If you changed your requirements to use "roles", we could make  
>> this work by checking what roles the user is in  
>> (request.isUserInRole(role))
>> I see a possible problem with the case you have an admin having to  
>> set preferences for each user (not sure if thats what you need,  
>> but it would be a problem as its not supported by the UI)
>> I think you could one time populate that with seed data, but it  
>> sounds like you need a way to edit preferences by an admin for a  
>> specific user
>> That is not supported. So I think I understand why you need to add/ 
>> remove entities and preferences. Here is the API:
>> http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/ 
>> apidocs/org/apache/jetspeed/components/portletentity/ 
>> PortletEntityAccessComponent.html
>> and yes, you can delete an entity, call
>> PortletEntity entity = entityAccess.getEntity("entityid");
>> entityAccess.removePortletEntity(entity);
> I can delete entities but from code and not from j2-admin, right?  
> no other way?

By deleting a portlet from a page using the customizer, it has the  
same effect

>> Of course you will need to delete the preferences associated with  
>> that entity, I think I already gave that code in another email
>> Another possible solution, using the Jetspeed SSO service. You can  
>> store your connection strings in the Jetspeed SSO storage, on a  
>> per group basis.
>> Connection strings can be configured on a per group basis, then  
>> you can retrieve the connection through a portlet (see the  
>> DatabaseBrowserPortlet for an example)
>> Take a look at the SSO Administrative portlet: You can setup the  
>> credentials there for a group
> This sounds interesting, I will look into this and will let you  
> know. It needs to do this from code ?

Yes, there isn't much code there really.
You must be writing some code already for the ReportPortlet, so you  
can just use the code provided as a basis, and leave the majority of  
the coding to the SSO component


As an aside, this makes me think of another approach using Java  
Permissions, which can be configured in Jetspeed.
I was thinking about setting up your own permission, say a

public class ConnectionPermission extends PortalResourcePermission

that would protect your connection strings, something like

		<Permission type="connection" resource="jdbc:mysql:connection1"  

of course that would take a enhancements to the XML support in  
Jetspeed and the administrative UI, but you could create these  
programmatically and add them to the system
I am not recommending this approach right now, just taking notes

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message