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 Mansour <ma...@yahoo.com> on 2007/11/01 02:13:24 UTC
Re: portlet entity Editor
David Sean Taylor wrote:
>
> On Oct 30, 2007, at 7:39 AM, Mansour wrote:
>
>> David Sean Taylor wrote:
>>>
>>> On Oct 27, 2007, at 3:27 PM, Mansour wrote:
>>>
>>>> From my understanding I can ( through the Entity Editor in JS2)
>>>> create new entities that are not added to the page. Also, I can
>>>> view the parameter for an exiting entity and modify them. When I
>>>> remove an entity form all the pages, it's not deleted from the
>>>> entity browser. There is no way to delete entities from the entity
>>>> browser. And I can not set permissions on an entity. In fact if I
>>>> create and entiy through the Entity browser, there's no way to add
>>>> it to the pages.
>>>>
>>> The entity editor was an early experiment in the Jetspeed XML API, I
>>> think we never really completed it
>>>
>>>> Now, how can I get around this:
>>>> 1- create and add an instance (or entity) to the pages?
>>>
>>> With the portlet customizer. Select the "Add Portlet" button and add
>>> a instance to a page
>>>
>>>> 2- set security permissions on this entity ?
>>>
>>> That has to be done by editing XML currently. Woonsan is working on
>>> an configure mode 2.1.3 which will handle this requirement
>>> You may want to double check with him though
>>>
>>>> 3- delete an entity.
>>>
>>> Go into edit mode, press the X for the portlet you want to delete
>> I do not mean delete an entity from the page only. I mean remove it
>> totally. Even if you remove if from the page as an admin. I t will be
>> removed fro all users. The entity will be there but not showing on
>> any page. Again, this is can be seen through the entity editor.
>>>
>
> I just think that the entity editor can get way out of hand for large
> systems, and where it may be a good debug tool, I usually just go to
> MySQL to query this kind of info
> Its still not clear to me why you need to manipulate entities at this
> low level. If you could better explain your use case, then I can
> better help you
>
>
I will give you an example of the use case for this. I have a reporting
portlet. This portlet (entity or portlet instance) is to pull and
display data from a customizable connection string. Users for group A
connect to DB A. Users in group B can pull data only form DB B. Users in
A and B have the choice to display or to hide this reporting portlet but
they cannot edit or customize the connection string. There's a system
Admin for group A called adminA and for B called adminB. The system
administrators can set this connection string and will revoke the
permission to edit this portlet from the groups. The system admins do
not and should not know anything about how to set permissions through
"PSML" (it's JS2 specific and not a standard like jsp). IF a portlet is
not used by any one then entity (instance) can be deleted from the DB by
the admin.
I hope this explains what I need to do. I am in the early stages of
designing my application, all I need to know is if this is possible or
not. If yes, then how?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Nov 7, 2007, at 8:30 AM, Mansour wrote:
> David Sean Taylor wrote:
>>
>> On Nov 4, 2007, at 11:40 PM, Mansour wrote:
>>
>>> Oops, the mail went to the public list. Not any private info yet.
>>> We can discuss this publicly and get more inputs from other users.
>>>
>> OK
>>
>>>
>>>
>>> Mansour wrote:
>>>> David, thank you for your help in this. I decided to exclude the
>>>> public mailing list form my reply in order to feel free in
>>>> giving info about what I am trying to do. Your last reply
>>>> resolved big part of the problem, and I just need to make sure
>>>> that I understand everything. Taking a real life example will
>>>> help a lot.
>>>>
>>>> Let's say I need to write a portlet "application" that contains
>>>> few reports for a hotel system:
>>>> 1- moth to date (MTD) revenue.
>>>> 2-YTD revenue.
>>>> 3- sales.
>>>> 4- expenses.
>>>> 5- report of empty rooms.
>>>> 6-report of rooms to be cleaned.
>>>> 7-rooms need maintenance.
>>>> ...
>>>>
>>>> This portlet application is to be hosted for few hotels on one
>>>> "single" portal server.
>>>> For each hotel, I need to create an instance. And I need to set
>>>> the DB connection and credentials and it should not be changed
>>>> by any one else.
>>
>> When you say instance, I think that term is confusing.
>> Basically you need a 1-1 relationship between a hotel and connection.
> The term instance is used in other portlet containers.
>>
>>>> When the user logs in , she has the choice to add this instance
>>>> to here page. She can add more than one instance and customize
>>>> them. For example, a revenue manager may add an instance and
>>>> using the edit mode she can configure this instance to show the
>>>> YTD revenue report. She may add another instance and configure
>>>> it to show the sales as well. The revenue manager has access to
>>>> any type of report she wants. The cleaning person in the hotel
>>>> should not view the expenses. She should only see the rooms to
>>>> be cleaned and may be maintenances. The maintenance guy should
>>>> not have access to the reports of empty rooms.
>>
>>
>>>> In this case I will create the number of reports I need (using
>>>> BIRT and eclipse) and wrap them in a portlet application. and
>>>> deploy it. Then I will customize the DB connection for each
>>>> hotel in the global preference ?? so no one can change it. Am I
>>>> right ?
>>
>> Yes, that is correct.
> Great so, how can I do this for multiple hotel. I mean in the
> global preferences there's only one DB connection string. As I
> mentioned earlier I will create only one package and then
> instantiate instances or entities. You said I need a 1-1
> relationship hotel-connection ! What do you mean? And how?
I was talking about using the SSO component with the code example
shown in the previous email
But when I say 1-1 relationship, I mean you add a SSO Record for each
hotel, and then look up the connection string using the hotel name as
a key
credentials = sso.getCredentials(getSubject(), hotelName);
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by Mansour <ma...@yahoo.com>.
David Sean Taylor wrote:
>
> On Nov 4, 2007, at 11:40 PM, Mansour wrote:
>
>> Oops, the mail went to the public list. Not any private info yet. We
>> can discuss this publicly and get more inputs from other users.
>>
> OK
>
>>
>>
>> Mansour wrote:
>>> David, thank you for your help in this. I decided to exclude the
>>> public mailing list form my reply in order to feel free in giving
>>> info about what I am trying to do. Your last reply resolved big part
>>> of the problem, and I just need to make sure that I understand
>>> everything. Taking a real life example will help a lot.
>>>
>>> Let's say I need to write a portlet "application" that contains few
>>> reports for a hotel system:
>>> 1- moth to date (MTD) revenue.
>>> 2-YTD revenue.
>>> 3- sales.
>>> 4- expenses.
>>> 5- report of empty rooms.
>>> 6-report of rooms to be cleaned.
>>> 7-rooms need maintenance.
>>> ...
>>>
>>> This portlet application is to be hosted for few hotels on one
>>> "single" portal server.
>>> For each hotel, I need to create an instance. And I need to set the
>>> DB connection and credentials and it should not be changed by any
>>> one else.
>
> When you say instance, I think that term is confusing.
> Basically you need a 1-1 relationship between a hotel and connection.
The term instance is used in other portlet containers.
>
>>> When the user logs in , she has the choice to add this instance to
>>> here page. She can add more than one instance and customize them.
>>> For example, a revenue manager may add an instance and using the
>>> edit mode she can configure this instance to show the YTD revenue
>>> report. She may add another instance and configure it to show the
>>> sales as well. The revenue manager has access to any type of report
>>> she wants. The cleaning person in the hotel should not view the
>>> expenses. She should only see the rooms to be cleaned and may be
>>> maintenances. The maintenance guy should not have access to the
>>> reports of empty rooms.
>
>
>>> In this case I will create the number of reports I need (using BIRT
>>> and eclipse) and wrap them in a portlet application. and deploy it.
>>> Then I will customize the DB connection for each hotel in the global
>>> preference ?? so no one can change it. Am I right ?
>
> Yes, that is correct.
Great so, how can I do this for multiple hotel. I mean in the global
preferences there's only one DB connection string. As I mentioned
earlier I will create only one package and then instantiate instances or
entities. You said I need a 1-1 relationship hotel-connection ! What do
you mean? And how?
>
>>>
>>> then I may give the users edit permissions so that they can choose
>>> what report to show. Correct ?
>>>
>
> You can protect your portlets in the deployment descriptor with a
> security constraint (jetspeed-portlet.xml) such as
>
> <portlet>
> <portlet-name>ExpensesReport</portlet-name>
>
> <js:security-constraint-ref>hotel-constraint</js:security-constraint-ref>
> ...
>
> The hotel constraint would grant view, edit to managers, and perhaps
> view to sales people, and deny all others
>
I am trying to avoid (as much as I can) to set permission through PSML
as this permissions need to be changed by the admin (The admin should
NOT know any PSML).
>
>>> Now, how can I tell jetspeed, don't let the cleaner see the expenses.
>
> By not providing a role to cleaners to view the the report:
>
> <security-constraints-def name="hotel-constraint">
> <security-constraint>
> <roles>sales</roles>
> <permissions>view</permissions>
> </security-constraint>
> <security-constraint>
> <roles>hotel-manager</roles>
> <permissions>view, edit, edit_defaults</permissions>
> </security-constraint>
> </security-constraints-def>
>
Same thing applies here !
>
>>> One way I though about is through the roles but don't I need the
>>> name of the reference of the entity "instance" ? if yes how can I
>>> get it? Further more, this has to be done by the administrator on
>>> the site (in the hotel). I can not give access to the j2-admin, and
>>> the admin can not use PSML. And this is where the confusion starts.
>>>
>>>
>>> On the other had, the entity is not deleted when yo remove it from
>>> the page, it's just hidden. If you go to the entity editor, you can
>>> see it there?
>>>
>
> Its orphaned I guess, although I thought we fixed that. Its no longer
> really useful and entities are very small database records.
> I seem to remember some way to clean up orphaned entities from the
> database, but actually I thought it was no longer necessary
>
>>> I hope things make sense now and you can understand what I am trying
>>> to do. You can adopt this example for any other application (ie. car
>>> rental, car dealership,...etc). I am still in the very early stages
>>> of this project and I am not in a rush to get know how to get this
>>> done know (it would be nice thou). The most important part to me is
>>> to know if it's possible and easy with JS2, and if not, do you see
>>> this will change in about 3 months from now?
>
> I think it is possible today with 2.1.2. Lets give it a try...
>
I am trying anyway. :)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Nov 4, 2007, at 11:40 PM, Mansour wrote:
> Oops, the mail went to the public list. Not any private info yet.
> We can discuss this publicly and get more inputs from other users.
>
OK
>
>
> Mansour wrote:
>> David, thank you for your help in this. I decided to exclude the
>> public mailing list form my reply in order to feel free in giving
>> info about what I am trying to do. Your last reply resolved big
>> part of the problem, and I just need to make sure that I
>> understand everything. Taking a real life example will help a lot.
>>
>> Let's say I need to write a portlet "application" that contains
>> few reports for a hotel system:
>> 1- moth to date (MTD) revenue.
>> 2-YTD revenue.
>> 3- sales.
>> 4- expenses.
>> 5- report of empty rooms.
>> 6-report of rooms to be cleaned.
>> 7-rooms need maintenance.
>> ...
>>
>> This portlet application is to be hosted for few hotels on one
>> "single" portal server.
>> For each hotel, I need to create an instance. And I need to set
>> the DB connection and credentials and it should not be changed by
>> any one else.
When you say instance, I think that term is confusing.
Basically you need a 1-1 relationship between a hotel and connection.
>> When the user logs in , she has the choice to add this instance to
>> here page. She can add more than one instance and customize them.
>> For example, a revenue manager may add an instance and using the
>> edit mode she can configure this instance to show the YTD revenue
>> report. She may add another instance and configure it to show the
>> sales as well. The revenue manager has access to any type of
>> report she wants. The cleaning person in the hotel should not view
>> the expenses. She should only see the rooms to be cleaned and may
>> be maintenances. The maintenance guy should not have access to the
>> reports of empty rooms.
>> In this case I will create the number of reports I need (using
>> BIRT and eclipse) and wrap them in a portlet application. and
>> deploy it. Then I will customize the DB connection for each hotel
>> in the global preference ?? so no one can change it. Am I right ?
Yes, that is correct.
>>
>> then I may give the users edit permissions so that they can choose
>> what report to show. Correct ?
>>
You can protect your portlets in the deployment descriptor with a
security constraint (jetspeed-portlet.xml) such as
<portlet>
<portlet-name>ExpensesReport</portlet-name>
<js:security-constraint-ref>hotel-constraint</js:security-
constraint-ref>
...
The hotel constraint would grant view, edit to managers, and perhaps
view to sales people, and deny all others
>> Now, how can I tell jetspeed, don't let the cleaner see the expenses.
By not providing a role to cleaners to view the the report:
<security-constraints-def name="hotel-constraint">
<security-constraint>
<roles>sales</roles>
<permissions>view</permissions>
</security-constraint>
<security-constraint>
<roles>hotel-manager</roles>
<permissions>view, edit, edit_defaults</permissions>
</security-constraint>
</security-constraints-def>
>> One way I though about is through the roles but don't I need the
>> name of the reference of the entity "instance" ? if yes how can I
>> get it? Further more, this has to be done by the administrator on
>> the site (in the hotel). I can not give access to the j2-admin,
>> and the admin can not use PSML. And this is where the confusion
>> starts.
>>
>>
>> On the other had, the entity is not deleted when yo remove it from
>> the page, it's just hidden. If you go to the entity editor, you
>> can see it there?
>>
Its orphaned I guess, although I thought we fixed that. Its no longer
really useful and entities are very small database records.
I seem to remember some way to clean up orphaned entities from the
database, but actually I thought it was no longer necessary
>> I hope things make sense now and you can understand what I am
>> trying to do. You can adopt this example for any other application
>> (ie. car rental, car dealership,...etc). I am still in the very
>> early stages of this project and I am not in a rush to get know
>> how to get this done know (it would be nice thou). The most
>> important part to me is to know if it's possible and easy with
>> JS2, and if not, do you see this will change in about 3 months
>> from now?
I think it is possible today with 2.1.2. Lets give it a try...
Re: portlet entity Editor
Posted by Mansour <ma...@yahoo.com>.
Oops, the mail went to the public list. Not any private info yet. We can
discuss this publicly and get more inputs from other users.
Mansour wrote:
> David, thank you for your help in this. I decided to exclude the
> public mailing list form my reply in order to feel free in giving info
> about what I am trying to do. Your last reply resolved big part of the
> problem, and I just need to make sure that I understand everything.
> Taking a real life example will help a lot.
>
> Let's say I need to write a portlet "application" that contains few
> reports for a hotel system:
> 1- moth to date (MTD) revenue.
> 2-YTD revenue.
> 3- sales.
> 4- expenses.
> 5- report of empty rooms.
> 6-report of rooms to be cleaned.
> 7-rooms need maintenance.
> ...
>
> This portlet application is to be hosted for few hotels on one
> "single" portal server.
> For each hotel, I need to create an instance. And I need to set the DB
> connection and credentials and it should not be changed by any one else.
> When the user logs in , she has the choice to add this instance to
> here page. She can add more than one instance and customize them. For
> example, a revenue manager may add an instance and using the edit mode
> she can configure this instance to show the YTD revenue report. She
> may add another instance and configure it to show the sales as well.
> The revenue manager has access to any type of report she wants. The
> cleaning person in the hotel should not view the expenses. She should
> only see the rooms to be cleaned and may be maintenances. The
> maintenance guy should not have access to the reports of empty rooms.
>
> In this case I will create the number of reports I need (using BIRT
> and eclipse) and wrap them in a portlet application. and deploy it.
> Then I will customize the DB connection for each hotel in the global
> preference ?? so no one can change it. Am I right ?
>
> then I may give the users edit permissions so that they can choose
> what report to show. Correct ?
>
> Now, how can I tell jetspeed, don't let the cleaner see the expenses.
> One way I though about is through the roles but don't I need the name
> of the reference of the entity "instance" ? if yes how can I get it?
> Further more, this has to be done by the administrator on the site (in
> the hotel). I can not give access to the j2-admin, and the admin can
> not use PSML. And this is where the confusion starts.
>
>
> On the other had, the entity is not deleted when yo remove it from the
> page, it's just hidden. If you go to the entity editor, you can see it
> there?
>
> I hope things make sense now and you can understand what I am trying
> to do. You can adopt this example for any other application (ie. car
> rental, car dealership,...etc). I am still in the very early stages of
> this project and I am not in a rush to get know how to get this done
> know (it would be nice thou). The most important part to me is to know
> if it's possible and easy with JS2, and if not, do you see this will
> change in about 3 months from now?
>
>
>
> Thank you for your help.
>
>
>
> David Sean Taylor wrote:
>>
>> 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
>> portlet.xml
>> 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:
>>
>> connectionString="jdbc:mysql:defaultServer"
>> username="default"
>> password="secret"
>>
>> and then the admin goes into edit defaults mode, and overrides the
>> connection to for a ReportPortlet placed on a page named
>> "ClientOne.psml":
>>
>> connectionString="jdbc:mysql:clientOneServer"
>> username="client1"
>> password="secret"
>>
>> and then the admin goes into edit defaults mode, and overrides the
>> connection to for a ReportPortlet placed on a page named
>> "ClientTwo.psml":
>>
>> connectionString="jdbc:mysql:clientTwoServer"
>> username="client2"
>> password="secret"
>>
>> 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
>> file
>> 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:
>>
>> <portlet>
>> <portlet-name>ClientOneReportPortlet</portlet-name>
>>
>> <js:security-constraint-ref>clientOne</js:security-constraint-ref>
>> ....
>> <portlet>
>> <portlet-name>ClientTwoReportPortlet</portlet-name>
>>
>> <js:security-constraint-ref>clientTwo</js:security-constraint-ref>
>>
>> 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" actions="connect">
>> <roles></roles>
>> <groups>one,two</groups>
>> </Permission>
>>
>> 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
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by Mansour <ma...@yahoo.com>.
David, thank you for your help in this. I decided to exclude the public
mailing list form my reply in order to feel free in giving info about
what I am trying to do. Your last reply resolved big part of the
problem, and I just need to make sure that I understand everything.
Taking a real life example will help a lot.
Let's say I need to write a portlet "application" that contains few
reports for a hotel system:
1- moth to date (MTD) revenue.
2-YTD revenue.
3- sales.
4- expenses.
5- report of empty rooms.
6-report of rooms to be cleaned.
7-rooms need maintenance.
...
This portlet application is to be hosted for few hotels on one "single"
portal server.
For each hotel, I need to create an instance. And I need to set the DB
connection and credentials and it should not be changed by any one else.
When the user logs in , she has the choice to add this instance to here
page. She can add more than one instance and customize them. For
example, a revenue manager may add an instance and using the edit mode
she can configure this instance to show the YTD revenue report. She may
add another instance and configure it to show the sales as well. The
revenue manager has access to any type of report she wants. The cleaning
person in the hotel should not view the expenses. She should only see
the rooms to be cleaned and may be maintenances. The maintenance guy
should not have access to the reports of empty rooms.
In this case I will create the number of reports I need (using BIRT and
eclipse) and wrap them in a portlet application. and deploy it. Then I
will customize the DB connection for each hotel in the global preference
?? so no one can change it. Am I right ?
then I may give the users edit permissions so that they can choose what
report to show. Correct ?
Now, how can I tell jetspeed, don't let the cleaner see the expenses.
One way I though about is through the roles but don't I need the name of
the reference of the entity "instance" ? if yes how can I get it?
Further more, this has to be done by the administrator on the site (in
the hotel). I can not give access to the j2-admin, and the admin can not
use PSML. And this is where the confusion starts.
On the other had, the entity is not deleted when yo remove it from the
page, it's just hidden. If you go to the entity editor, you can see it
there?
I hope things make sense now and you can understand what I am trying to
do. You can adopt this example for any other application (ie. car
rental, car dealership,...etc). I am still in the very early stages of
this project and I am not in a rush to get know how to get this done
know (it would be nice thou). The most important part to me is to know
if it's possible and easy with JS2, and if not, do you see this will
change in about 3 months from now?
Thank you for your help.
David Sean Taylor wrote:
>
> 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 portlet.xml
> 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:
>
> connectionString="jdbc:mysql:defaultServer"
> username="default"
> password="secret"
>
> and then the admin goes into edit defaults mode, and overrides the
> connection to for a ReportPortlet placed on a page named
> "ClientOne.psml":
>
> connectionString="jdbc:mysql:clientOneServer"
> username="client1"
> password="secret"
>
> and then the admin goes into edit defaults mode, and overrides the
> connection to for a ReportPortlet placed on a page named
> "ClientTwo.psml":
>
> connectionString="jdbc:mysql:clientTwoServer"
> username="client2"
> password="secret"
>
> 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
> file
> 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:
>
> <portlet>
> <portlet-name>ClientOneReportPortlet</portlet-name>
>
> <js:security-constraint-ref>clientOne</js:security-constraint-ref>
> ....
> <portlet>
> <portlet-name>ClientTwoReportPortlet</portlet-name>
>
> <js:security-constraint-ref>clientTwo</js:security-constraint-ref>
>
> 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" actions="connect">
> <roles></roles>
> <groups>one,two</groups>
> </Permission>
>
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
portlet.xml
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:
connectionString="jdbc:mysql:defaultServer"
username="default"
password="secret"
and then the admin goes into edit defaults mode, and overrides the
connection to for a ReportPortlet placed on a page named
"ClientOne.psml":
connectionString="jdbc:mysql:clientOneServer"
username="client1"
password="secret"
and then the admin goes into edit defaults mode, and overrides the
connection to for a ReportPortlet placed on a page named
"ClientTwo.psml":
connectionString="jdbc:mysql:clientTwoServer"
username="client2"
password="secret"
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
file
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:
<portlet>
<portlet-name>ClientOneReportPortlet</portlet-name>
<js:security-constraint-ref>clientOne</js:security-
constraint-ref>
....
<portlet>
<portlet-name>ClientTwoReportPortlet</portlet-name>
<js:security-constraint-ref>clientTwo</js:security-
constraint-ref>
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"
actions="connect">
<roles></roles>
<groups>one,two</groups>
</Permission>
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
Re: portlet entity Editor
Posted by Mansour <ma...@yahoo.com>.
David Sean Taylor wrote:
>
> On Oct 31, 2007, at 6:13 PM, Mansour wrote:
>
>> David Sean Taylor wrote:
>>>
>>> On Oct 30, 2007, at 7:39 AM, Mansour wrote:
>>>
>>>> David Sean Taylor wrote:
>>>>>
>>>>> On Oct 27, 2007, at 3:27 PM, Mansour wrote:
>>>>>
>>>>>> From my understanding I can ( through the Entity Editor in JS2)
>>>>>> create new entities that are not added to the page. Also, I can
>>>>>> view the parameter for an exiting entity and modify them. When I
>>>>>> remove an entity form all the pages, it's not deleted from the
>>>>>> entity browser. There is no way to delete entities from the
>>>>>> entity browser. And I can not set permissions on an entity. In
>>>>>> fact if I create and entiy through the Entity browser, there's no
>>>>>> way to add it to the pages.
>>>>>>
>>>>> The entity editor was an early experiment in the Jetspeed XML API,
>>>>> I think we never really completed it
>>>>>
>>>>>> Now, how can I get around this:
>>>>>> 1- create and add an instance (or entity) to the pages?
>>>>>
>>>>> With the portlet customizer. Select the "Add Portlet" button and
>>>>> add a instance to a page
>>>>>
>>>>>> 2- set security permissions on this entity ?
>>>>>
>>>>> That has to be done by editing XML currently. Woonsan is working
>>>>> on an configure mode 2.1.3 which will handle this requirement
>>>>> You may want to double check with him though
>>>>>
>>>>>> 3- delete an entity.
>>>>>
>>>>> Go into edit mode, press the X for the portlet you want to delete
>>>> I do not mean delete an entity from the page only. I mean remove it
>>>> totally. Even if you remove if from the page as an admin. I t will
>>>> be removed fro all users. The entity will be there but not showing
>>>> on any page. Again, this is can be seen through the entity editor.
>>>>>
>>>
>>> I just think that the entity editor can get way out of hand for
>>> large systems, and where it may be a good debug tool, I usually just
>>> go to MySQL to query this kind of info
>>> Its still not clear to me why you need to manipulate entities at
>>> this low level. If you could better explain your use case, then I
>>> can better help you
>>>
>>>
>>
>> I will give you an example of the use case for this. I have a
>> reporting portlet. This portlet (entity or portlet instance) is to
>> pull and display data from a customizable connection string. Users
>> for group A connect to DB A. Users in group B can pull data only form
>> DB B. Users in A and B have the choice to display or to hide this
>> reporting portlet but they cannot edit or customize the connection
>> string. There's a system Admin for group A called adminA and for B
>> called adminB. The system administrators can set this connection
>> string and will revoke the permission to edit this portlet from the
>> groups. The system admins do not and should not know anything about
>> how to set permissions through "PSML" (it's JS2 specific and not a
>> standard like jsp). IF a portlet is not used by any one then entity
>> (instance) can be deleted from the DB by the admin.
>>
>
> 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.
> 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.
>
> 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?
> 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?
> 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 ?
> In your portlet, then you just get the credential (a connection
> strong) via a sso.getCredentials call.
> Here we use a combination of SSO storage and preferences storage for
> the connection string, since the credentials need to be encrypted
> This is a snippet from the DatabaseBrowserPortlet:
>
> BasicDataSource ds = new BasicDataSource();
> ds.setDriverClassName(prefs.getValue("SSOJdbcDriver",
> ""));
> ds.setUrl(prefs.getValue("SSOJdbcConnection", ""));
> String ssoURL = prefs.getValue("SSOSite", "");
>
> // SSO API lookup
> SSOContext credentials = null;
> try
> {
> if (sso == null)
> throw new SSOException("SSO Not supported.");
>
> credentials = sso.getCredentials(getSubject(),
> ssoURL);
> }
> catch(SSOException ssoex)
> {
> throw new Exception("SSO credential lookup failed.
> Error: " + ssoex.getMessage());
> }
>
> String ssoUserName =
> credentials.getRemotePrincipalName();
> String ssoPWD = credentials.getRemoteCredential();
> ds.setUsername(ssoUserName);
> ds.setPassword( ssoPWD );
> con = ds.getConnection();
>
>
> it will find credentials based on the user's group membership or by
> specific user, depending on how your administrator configured it
> Albeit its not fully portable, it does very nicely abstract the SSO
> functionality into a service paradigm with a supported-open-source API
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: portlet entity Editor
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Oct 31, 2007, at 6:13 PM, Mansour wrote:
> David Sean Taylor wrote:
>>
>> On Oct 30, 2007, at 7:39 AM, Mansour wrote:
>>
>>> David Sean Taylor wrote:
>>>>
>>>> On Oct 27, 2007, at 3:27 PM, Mansour wrote:
>>>>
>>>>> From my understanding I can ( through the Entity Editor in JS2)
>>>>> create new entities that are not added to the page. Also, I can
>>>>> view the parameter for an exiting entity and modify them. When
>>>>> I remove an entity form all the pages, it's not deleted from
>>>>> the entity browser. There is no way to delete entities from the
>>>>> entity browser. And I can not set permissions on an entity. In
>>>>> fact if I create and entiy through the Entity browser, there's
>>>>> no way to add it to the pages.
>>>>>
>>>> The entity editor was an early experiment in the Jetspeed XML
>>>> API, I think we never really completed it
>>>>
>>>>> Now, how can I get around this:
>>>>> 1- create and add an instance (or entity) to the pages?
>>>>
>>>> With the portlet customizer. Select the "Add Portlet" button and
>>>> add a instance to a page
>>>>
>>>>> 2- set security permissions on this entity ?
>>>>
>>>> That has to be done by editing XML currently. Woonsan is working
>>>> on an configure mode 2.1.3 which will handle this requirement
>>>> You may want to double check with him though
>>>>
>>>>> 3- delete an entity.
>>>>
>>>> Go into edit mode, press the X for the portlet you want to delete
>>> I do not mean delete an entity from the page only. I mean remove
>>> it totally. Even if you remove if from the page as an admin. I t
>>> will be removed fro all users. The entity will be there but not
>>> showing on any page. Again, this is can be seen through the
>>> entity editor.
>>>>
>>
>> I just think that the entity editor can get way out of hand for
>> large systems, and where it may be a good debug tool, I usually
>> just go to MySQL to query this kind of info
>> Its still not clear to me why you need to manipulate entities at
>> this low level. If you could better explain your use case, then I
>> can better help you
>>
>>
>
> I will give you an example of the use case for this. I have a
> reporting portlet. This portlet (entity or portlet instance) is to
> pull and display data from a customizable connection string. Users
> for group A connect to DB A. Users in group B can pull data only
> form DB B. Users in A and B have the choice to display or to hide
> this reporting portlet but they cannot edit or customize the
> connection string. There's a system Admin for group A called adminA
> and for B called adminB. The system administrators can set this
> connection string and will revoke the permission to edit this
> portlet from the groups. The system admins do not and should not
> know anything about how to set permissions through "PSML" (it's JS2
> specific and not a standard like jsp). IF a portlet is not used by
> any one then entity (instance) can be deleted from the DB by the
> admin.
>
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".
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
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:
groupA-connection = jdbc:mysql://server1/schema1
groupB-connection = jdbc:mysql://server2/schema2
groupC-connection = jdbc:mysql://server2:schema3
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);
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
In your portlet, then you just get the credential (a connection
strong) via a sso.getCredentials call.
Here we use a combination of SSO storage and preferences storage for
the connection string, since the credentials need to be encrypted
This is a snippet from the DatabaseBrowserPortlet:
BasicDataSource ds = new BasicDataSource();
ds.setDriverClassName(prefs.getValue
("SSOJdbcDriver", ""));
ds.setUrl(prefs.getValue("SSOJdbcConnection", ""));
String ssoURL = prefs.getValue("SSOSite", "");
// SSO API lookup
SSOContext credentials = null;
try
{
if (sso == null)
throw new SSOException("SSO Not supported.");
credentials = sso.getCredentials(getSubject(),
ssoURL);
}
catch(SSOException ssoex)
{
throw new Exception("SSO credential lookup
failed. Error: " + ssoex.getMessage());
}
String ssoUserName =
credentials.getRemotePrincipalName();
String ssoPWD = credentials.getRemoteCredential();
ds.setUsername(ssoUserName);
ds.setPassword( ssoPWD );
con = ds.getConnection();
it will find credentials based on the user's group membership or by
specific user, depending on how your administrator configured it
Albeit its not fully portable, it does very nicely abstract the SSO
functionality into a service paradigm with a supported-open-source API