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 Joachim Müller <jo...@wemove.com> on 2010/01/13 00:39:52 UTC
New User/Group/Role Management Portlet
Hi,
I want to create new User/Group/Role Management portlets that are easier
to use/understand. The main requirements are:
- easy to understand UI
- simple but powerful query interface
- paging for the principal results list
- be able to work with 10.000+ users in terms of memory/performance
To accomplish the requirements I would like to introduce a
JetspeedPrincipalLookupManager with the method:
JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
queryContext);
The JetspeedPrincipalQueryContext holds all possible query parameters
(principal name, attributes, asscoiatedRoles, asscoiatedGroups,
asscoiatedUsers, sort order, paging parameters, etc.).
The JetspeedPrincipalResultList encapsulates the actual list of detached
JetspeedPrincipals and the total number of results.
The JetspeedPrincipalLookupManager will be implemented using plain JDBC
because paging the result set is not/poorly supported by OJB. Database
specific LookupManager implementations can be plugged in via Spring and
can handle database supported paging (like MySqls LIMIT) but there is a
default implementation that uses plain JDBC for paging the result set.
The DB platform is derived from OJB, there is no extra config parameter
to take care of.
I am planing to plug the JetspeedPrincipalLookupManager into the
JetspeedSecurityPersistenceManager via Spring.
Any comments on that plan? Anything I have to be aware of?
Thanks for any comment,
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by David Sean Taylor <d....@onehippo.com>.
On Tue, Jan 12, 2010 at 3:39 PM, Joachim Müller <jo...@wemove.com> wrote:
> Hi,
>
> I want to create new User/Group/Role Management portlets that are easier
> to use/understand. The main requirements are:
>
> - easy to understand UI
> - simple but powerful query interface
> - paging for the principal results list
> - be able to work with 10.000+ users in terms of memory/performance
>
> To accomplish the requirements I would like to introduce a
> JetspeedPrincipalLookupManager with the method:
>
> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> queryContext);
>
> The JetspeedPrincipalQueryContext holds all possible query parameters
> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
> asscoiatedUsers, sort order, paging parameters, etc.).
>
> The JetspeedPrincipalResultList encapsulates the actual list of detached
> JetspeedPrincipals and the total number of results.
>
> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
> because paging the result set is not/poorly supported by OJB. Database
> specific LookupManager implementations can be plugged in via Spring and
> can handle database supported paging (like MySqls LIMIT) but there is a
> default implementation that uses plain JDBC for paging the result set.
> The DB platform is derived from OJB, there is no extra config parameter
> to take care of.
>
> I am planing to plug the JetspeedPrincipalLookupManager into the
> JetspeedSecurityPersistenceManager via Spring.
>
> Any comments on that plan? Anything I have to be aware of?
>
>
+1
Re: New User/Group/Role Management Portlet
Posted by Ate Douma <at...@douma.nu>.
Hi Joachim and Woonsan,
Sorry for chiming in a bit late on this discussion but I've been thinking about this "issue" too in the past so I'd like to give my 2c as
well (see still open issue JS2-241, created April 26, 2005...).
First of all I have an additional feature suggestion.
I think we should also consider supporting "reporting queries" for a new pageable search solution.
With that I mean that the returned result set not only supports only fully typed objects, like JetspeedPrincipal as in your current
proposal, but also "partial" or unstructured "data" records, like only "username" or "id, given name, family name, enabled(boolean)", etc.
This will be particular useful for more optimal and lightweight front-end usage, like principal browsers which only need to present and
maintain shallow data and don't need a "heavy weight" JetspeedPrincipal object with all possible relationships, attributes pulled in behind
the scenes.
Both OJB (albeit (very)limited and possibly/probably with implementation problems) but also and in particular the JPA (2.0) Query Criteria
API does provide such "reporting" query result capabilities.
I've always envisioned we should come op for Jetspeed with a QueryCriteria API of our own, mimicking the JPA Query Criteria API to remain
independent of engine (e.g. OJB/JPA/JDO etc.) specific API constructs *and* for backporting support like to Jetspeed 2.1.x.
Or, simply just adopt the JPA Query Criteria *API* fully.
Doing the latter might (should) still allow a different wrapping implementation on top for instance OJB or plain JDBC if we want.
The point would be to have a transparent and painless full blown JPA integration if/once we are ready to switch over to JPA.
In my opinion, that would be the best route *to investigate* first. Depending on that investigation, and with concrete information if this
would be possible and how much effort it would take to provide such "bridging" solution now, we will be better informed to make a good
decision. If it turns out this is extremely difficult or even impossible to do, we can still choose a more "practical" or direct solution
and come up with our own "proprietary" API to solve this. But I'd like to advise against starting out doing so right now until we are sure
there is no other or better way.
I really think going JPA is something we'll have to do sometime sooner or later to improve and thereafter maintain our integration
capabilities and because we should strive to stick to "standard" solution as much as possible (if feasible and practical).
Randy already spend a lot of time last year trying to do so in a separate branch with imo very good results. But regrettably, proper
evaluating and accepting all that effort didn't work out well in the light of the imminent 2.2.0 release at that time.
It would be good to consider restarting that effort soon imo...
I also think OJB is a dead project, meaning investing in further OJB usage or even trying to upgrade to an unreleased 1.0.5 version, with
potentially unknown new issues which will *not* be fixed anymore, is not advisable. Let alone that ASF release policy doesn't really support
us in releasing another projects unreleased artifact, unless we take over the responsibility of validating and support that ourselves.
Another note I'd like to make is that while pageable query support is very important for Security, we have similar requirements in the area
of Page management too. Consider 100k users each with their own userpsml(s). Our Page/Site manager API definitely needs improvement for this
too. That is another reason why I propose we should leverage a generic/standard (based) query criteria API instead of devising a tailer-made
one only usable for Security. That would be inefficient both API and implementation wise in the long run.
With regard to using direct JDBC, I'm not really against using that for an intermediate solution, with the caveat it might not play well
with caches maintained by the (OJB/JPA) engine. Please do take note of possible cache synchronization needs.
Also, we already do use direct JDBC in some other components as well (like the statistics, but also others).
But when using JDBC as an intermediate solution, coming up with a resilient and stable API which anticipates migrating to preferably JPA in
the future is imo critical, otherwise we'll end up with yet even more hefty API and (front-end) migration requirements later on.
Regards,
Ate
On 01/19/2010 05:22 AM, Joachim Müller wrote:
> Hi Woonsan,
>
> I also did look into 1.0.5rc1 and would very much prefer a stable OJB
> over the JDBC solution. But since I am not as experienced in
> Jetspeed/OJB and do not overlook all changes that have to be made,
> exchanging the OJB version (there is more than just replacing the jar!!)
> AND the OJB was not released and there are some issues left
>
> http://issues.apache.org/jira/secure/BrowseProject.jspa
>
> I decided to use the plain JDBC approach, which is DB platform independent.
>
> Anyway, I would like to leave this decision to the more experienced
> developers. If we can agree about the way of implementing
> (JetspeedPrincipalLookupManager) this JDBC component could be easily
> replaced by a OJB based solution. Actually my main thought was replacing
> the user manager and this is a necessary API extension. Also I already
> implemented it :-) and could move on with the front end implementation.
>
> So the real important decision for me is on the new API method:
>
> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> queryContext);
>
> Is there anything standing against this?
>
> Regards,
> Joachim
>
>
> Am 18.01.2010 02:47, schrieb Woonsan Ko:
>> Hi Joachim,
>>
>>
>>
>> ----- Original Message ----
>>> From: Joachim Müller<jo...@wemove.com>
>>> To: jetspeed-dev@portals.apache.org
>>> Sent: Sat, January 16, 2010 1:04:13 PM
>>> Subject: Re: New User/Group/Role Management Portlet
>>>
>>> Hi Woonsan,
>>>
>>> thanks for the comments. I did check out the "upcoming" OJB 1.0.5 as
>>> well but the "upcoming" takes time since the 1.0.5-rc1 version
>>> was released at 29-Jan-2008 and the last commit on the project was on
>>> 31-Jan-2008. It seems OJB is a dead project.
>>
>> Probably. However we need to stick to it if we're not ready to move toany other framework yet. ;-)
>>
>>>
>>> The other option would be to wait until the JPA integration is there.
>>> But I think this is a major change and therefore not to be expected in
>>> the very near future. (I think Randy was already working on this already...)
>>>
>>
>> I don't know if the current OpenJPA or the comming OpenJPA 2.0 supports dbms-specific-optimized pagination query options.
>> JPA 2.0 Specification defines pagination APIs in query interfaces though.
>> Also, we probably replace the current OJB by JPA in the future, but I don't know how close it would be even in the trunk. Does anybody have an idea on this?
>>
>>> And last but not least I wanted to create a 2.1.4 compatible solutionto
>>> be backported.
>>
>> If we need to support 2.1.4 or 2.1.3 as well, then I think we'd betteradopt the new OJB maintenance release for the pagination support. It's simply because it wouldn't require any significant changes, with transparent pagination support on every database platform.
>>
>>>
>>> I am perfectly sure that this will be an intermediate solution for the
>>> trunk until the JPA implementation is there, but I think the current
>>> solution needs to be upgraded ASAP, because it is not suitable for
>>> installations with big numbers of users (no database level paging support).
>>
>> Agreed.
>> My two cents is that we could stick to the new OJB maintenance releasefor that if there's any technical issues with the new OJB release.
>> Is anybody aware of any technical problem?
>>
>> Regards,
>>
>> Woonsan
>>
>>>
>>> Regards,
>>> Joachim
>>>
>>>
>>>
>>> Am 15.01.2010 07:01, schrieb Woonsan Ko:
>>>> Hi Joachim,
>>>>
>>>> Please see my comments below.
>>>>
>>>>
>>>>
>>>> ----- Original Message ----
>>>>> From: Joachim Müller
>>>>> To: Jetspeed Developers List
>>>>> Sent: Wed, January 13, 2010 12:39:52 AM
>>>>> Subject: New User/Group/Role Management Portlet
>>>>>
>>>>> Hi,
>>>>>
>>>>> I want to create new User/Group/Role Management portlets that are easier
>>>>> to use/understand. The main requirements are:
>>>>>
>>>>> - easy to understand UI
>>>>> - simple but powerful query interface
>>>>> - paging for the principal results list
>>>>> - be able to work with 10.000+ users in terms of memory/performance
>>>>>
>>>>> To accomplish the requirements I would like to introduce a
>>>>> JetspeedPrincipalLookupManager with the method:
>>>>>
>>>>> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
>>>>> queryContext);
>>>>>
>>>>> The JetspeedPrincipalQueryContext holds all possible query parameters
>>>>> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
>>>>> asscoiatedUsers, sort order, paging parameters, etc.).
>>>>>
>>>>> The JetspeedPrincipalResultList encapsulates the actual list of detached
>>>>> JetspeedPrincipals and the total number of results.
>>>>>
>>>>> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
>>>>> because paging the result set is not/poorly supported by OJB. Database
>>>>> specific LookupManager implementations can be plugged in via Springand
>>>>> can handle database supported paging (like MySqls LIMIT) but there is a
>>>>> default implementation that uses plain JDBC for paging the result set.
>>>>> The DB platform is derived from OJB, there is no extra config parameter
>>>>> to take care of.
>>>>
>>>> I tried to search any framework level support for the DBMS-side pagination
>>> queries.
>>>> OJB seems now ready to support that feature since 1.0.5. It has beenadded
>>> with this issue: http://issues.apache.org/jira/browse/OJB-131
>>>> Also, I had a look at some source codes such as PlatformOracleImpl [1],
>>> PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package,
>>> org.apache.ojb.broker.platforms). Each one seems to use its own platform
>>> specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
>>>> You could have a look at those in addLimitSql() method and addPagingSql()
>>> method in each class.
>>>> I think we can ask OJB team to make a release of 1.0.5 and we'd better use new
>>> OJB or any other framework having same features.
>>>>
>>>> [1]
>>> https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
>>>>
>>>> Kind regards,
>>>>
>>>> Woonsan
>>>>
>>>>>
>>>>> I am planing to plug the JetspeedPrincipalLookupManager into the
>>>>> JetspeedSecurityPersistenceManager via Spring.
>>>>>
>>>>> Any comments on that plan? Anything I have to be aware of?
>>>>>
>>>>> Thanks for any comment,
>>>>> Joachim
>>>>>
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Joachim,
Please see comments below.
----- Original Message ----
> From: Joachim Müller <jo...@wemove.com>
> To: jetspeed-dev@portals.apache.org
> Sent: Tue, January 19, 2010 5:22:06 AM
> Subject: Re: New User/Group/Role Management Portlet
>
> Hi Woonsan,
>
> I also did look into 1.0.5rc1 and would very much prefer a stable OJB
> over the JDBC solution. But since I am not as experienced in
> Jetspeed/OJB and do not overlook all changes that have to be made,
> exchanging the OJB version (there is more than just replacing the jar!!)
> AND the OJB was not released and there are some issues left
>
> http://issues.apache.org/jira/secure/BrowseProject.jspa
>
> I decided to use the plain JDBC approach, which is DB platform independent.
>
> Anyway, I would like to leave this decision to the more experienced
> developers. If we can agree about the way of implementing
> (JetspeedPrincipalLookupManager) this JDBC component could be easily
> replaced by a OJB based solution. Actually my main thought was replacing
> the user manager and this is a necessary API extension. Also I already
> implemented it :-) and could move on with the front end implementation.
Oh, I don't think we should use OJB only for this. It seems okay to have JDBC based implementation because platform specific pagination support was not much in OJB as well and you already implemented one. ;-)
>
> So the real important decision for me is on the new API method:
>
> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> queryContext);
>
> Is there anything standing against this?
Nothing.
+1 from my side.
Kind regards,
Woonsan
>
> Regards,
> Joachim
>
>
> Am 18.01.2010 02:47, schrieb Woonsan Ko:
> > Hi Joachim,
> >
> >
> >
> > ----- Original Message ----
> >> From: Joachim Müller
> >> To: jetspeed-dev@portals.apache.org
> >> Sent: Sat, January 16, 2010 1:04:13 PM
> >> Subject: Re: New User/Group/Role Management Portlet
> >>
> >> Hi Woonsan,
> >>
> >> thanks for the comments. I did check out the "upcoming" OJB 1.0.5 as
> >> well but the "upcoming" takes time since the 1.0.5-rc1 version
> >> was released at 29-Jan-2008 and the last commit on the project was on
> >> 31-Jan-2008. It seems OJB is a dead project.
> >
> > Probably. However we need to stick to it if we're not ready to move to any
> other framework yet. ;-)
> >
> >>
> >> The other option would be to wait until the JPA integration is there.
> >> But I think this is a major change and therefore not to be expected in
> >> the very near future. (I think Randy was already working on this already...)
> >>
> >
> > I don't know if the current OpenJPA or the comming OpenJPA 2.0 supports
> dbms-specific-optimized pagination query options.
> > JPA 2.0 Specification defines pagination APIs in query interfaces though.
> > Also, we probably replace the current OJB by JPA in the future, but I don't
> know how close it would be even in the trunk. Does anybody have an idea on this?
> >
> >> And last but not least I wanted to create a 2.1.4 compatible solution to
> >> be backported.
> >
> > If we need to support 2.1.4 or 2.1.3 as well, then I think we'd better adopt
> the new OJB maintenance release for the pagination support. It's simply because
> it wouldn't require any significant changes, with transparent pagination support
> on every database platform.
> >
> >>
> >> I am perfectly sure that this will be an intermediate solution for the
> >> trunk until the JPA implementation is there, but I think the current
> >> solution needs to be upgraded ASAP, because it is not suitable for
> >> installations with big numbers of users (no database level paging support).
> >
> > Agreed.
> > My two cents is that we could stick to the new OJB maintenance release for
> that if there's any technical issues with the new OJB release.
> > Is anybody aware of any technical problem?
> >
> > Regards,
> >
> > Woonsan
> >
> >>
> >> Regards,
> >> Joachim
> >>
> >>
> >>
> >> Am 15.01.2010 07:01, schrieb Woonsan Ko:
> >>> Hi Joachim,
> >>>
> >>> Please see my comments below.
> >>>
> >>>
> >>>
> >>> ----- Original Message ----
> >>>> From: Joachim Müller
> >>>> To: Jetspeed Developers List
> >>>> Sent: Wed, January 13, 2010 12:39:52 AM
> >>>> Subject: New User/Group/Role Management Portlet
> >>>>
> >>>> Hi,
> >>>>
> >>>> I want to create new User/Group/Role Management portlets that are easier
> >>>> to use/understand. The main requirements are:
> >>>>
> >>>> - easy to understand UI
> >>>> - simple but powerful query interface
> >>>> - paging for the principal results list
> >>>> - be able to work with 10.000+ users in terms of memory/performance
> >>>>
> >>>> To accomplish the requirements I would like to introduce a
> >>>> JetspeedPrincipalLookupManager with the method:
> >>>>
> >>>> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> >>>> queryContext);
> >>>>
> >>>> The JetspeedPrincipalQueryContext holds all possible query parameters
> >>>> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
> >>>> asscoiatedUsers, sort order, paging parameters, etc.).
> >>>>
> >>>> The JetspeedPrincipalResultList encapsulates the actual list of detached
> >>>> JetspeedPrincipals and the total number of results.
> >>>>
> >>>> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
> >>>> because paging the result set is not/poorly supported by OJB. Database
> >>>> specific LookupManager implementations can be plugged in via Spring and
> >>>> can handle database supported paging (like MySqls LIMIT) but there is a
> >>>> default implementation that uses plain JDBC for paging the result set.
> >>>> The DB platform is derived from OJB, there is no extra config parameter
> >>>> to take care of.
> >>>
> >>> I tried to search any framework level support for the DBMS-side pagination
> >> queries.
> >>> OJB seems now ready to support that feature since 1.0.5. It has been added
> >> with this issue: http://issues.apache.org/jira/browse/OJB-131
> >>> Also, I had a look at some source codes such as PlatformOracleImpl [1],
> >> PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package,
> >> org.apache.ojb.broker.platforms). Each one seems to use its own platform
> >> specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
> >>> You could have a look at those in addLimitSql() method and addPagingSql()
> >> method in each class.
> >>> I think we can ask OJB team to make a release of 1.0.5 and we'd better use
> new
> >> OJB or any other framework having same features.
> >>>
> >>> [1]
> >>
> https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
> >>>
> >>> Kind regards,
> >>>
> >>> Woonsan
> >>>
> >>>>
> >>>> I am planing to plug the JetspeedPrincipalLookupManager into the
> >>>> JetspeedSecurityPersistenceManager via Spring.
> >>>>
> >>>> Any comments on that plan? Anything I have to be aware of?
> >>>>
> >>>> Thanks for any comment,
> >>>> Joachim
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>
> >>>
> >>
> >> --
> >>
> >> < joachim müller
> >> joachim@wemove.com
> >>
> >> wemove digital solutions gmbh
> >> eschersheimer landstr. 5-7
> >> 60322 frankfurt am main
> >>
> >> amtsgericht frankfurt am main, hrb 53992
> >> geschäftsführer joachim müller, stefan hartmann
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
>
> --
>
> < joachim müller
> joachim@wemove.com
>
> wemove digital solutions gmbh
> eschersheimer landstr. 5-7
> 60322 frankfurt am main
>
> amtsgericht frankfurt am main, hrb 53992
> geschäftsführer joachim müller, stefan hartmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by Joachim Müller <jo...@wemove.com>.
Hi Woonsan,
I also did look into 1.0.5rc1 and would very much prefer a stable OJB
over the JDBC solution. But since I am not as experienced in
Jetspeed/OJB and do not overlook all changes that have to be made,
exchanging the OJB version (there is more than just replacing the jar!!)
AND the OJB was not released and there are some issues left
http://issues.apache.org/jira/secure/BrowseProject.jspa
I decided to use the plain JDBC approach, which is DB platform independent.
Anyway, I would like to leave this decision to the more experienced
developers. If we can agree about the way of implementing
(JetspeedPrincipalLookupManager) this JDBC component could be easily
replaced by a OJB based solution. Actually my main thought was replacing
the user manager and this is a necessary API extension. Also I already
implemented it :-) and could move on with the front end implementation.
So the real important decision for me is on the new API method:
JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
queryContext);
Is there anything standing against this?
Regards,
Joachim
Am 18.01.2010 02:47, schrieb Woonsan Ko:
> Hi Joachim,
>
>
>
> ----- Original Message ----
>> From: Joachim Müller <jo...@wemove.com>
>> To: jetspeed-dev@portals.apache.org
>> Sent: Sat, January 16, 2010 1:04:13 PM
>> Subject: Re: New User/Group/Role Management Portlet
>>
>> Hi Woonsan,
>>
>> thanks for the comments. I did check out the "upcoming" OJB 1.0.5 as
>> well but the "upcoming" takes time since the 1.0.5-rc1 version
>> was released at 29-Jan-2008 and the last commit on the project was on
>> 31-Jan-2008. It seems OJB is a dead project.
>
> Probably. However we need to stick to it if we're not ready to move to any other framework yet. ;-)
>
>>
>> The other option would be to wait until the JPA integration is there.
>> But I think this is a major change and therefore not to be expected in
>> the very near future. (I think Randy was already working on this already...)
>>
>
> I don't know if the current OpenJPA or the comming OpenJPA 2.0 supports dbms-specific-optimized pagination query options.
> JPA 2.0 Specification defines pagination APIs in query interfaces though.
> Also, we probably replace the current OJB by JPA in the future, but I don't know how close it would be even in the trunk. Does anybody have an idea on this?
>
>> And last but not least I wanted to create a 2.1.4 compatible solution to
>> be backported.
>
> If we need to support 2.1.4 or 2.1.3 as well, then I think we'd better adopt the new OJB maintenance release for the pagination support. It's simply because it wouldn't require any significant changes, with transparent pagination support on every database platform.
>
>>
>> I am perfectly sure that this will be an intermediate solution for the
>> trunk until the JPA implementation is there, but I think the current
>> solution needs to be upgraded ASAP, because it is not suitable for
>> installations with big numbers of users (no database level paging support).
>
> Agreed.
> My two cents is that we could stick to the new OJB maintenance release for that if there's any technical issues with the new OJB release.
> Is anybody aware of any technical problem?
>
> Regards,
>
> Woonsan
>
>>
>> Regards,
>> Joachim
>>
>>
>>
>> Am 15.01.2010 07:01, schrieb Woonsan Ko:
>>> Hi Joachim,
>>>
>>> Please see my comments below.
>>>
>>>
>>>
>>> ----- Original Message ----
>>>> From: Joachim Müller
>>>> To: Jetspeed Developers List
>>>> Sent: Wed, January 13, 2010 12:39:52 AM
>>>> Subject: New User/Group/Role Management Portlet
>>>>
>>>> Hi,
>>>>
>>>> I want to create new User/Group/Role Management portlets that are easier
>>>> to use/understand. The main requirements are:
>>>>
>>>> - easy to understand UI
>>>> - simple but powerful query interface
>>>> - paging for the principal results list
>>>> - be able to work with 10.000+ users in terms of memory/performance
>>>>
>>>> To accomplish the requirements I would like to introduce a
>>>> JetspeedPrincipalLookupManager with the method:
>>>>
>>>> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
>>>> queryContext);
>>>>
>>>> The JetspeedPrincipalQueryContext holds all possible query parameters
>>>> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
>>>> asscoiatedUsers, sort order, paging parameters, etc.).
>>>>
>>>> The JetspeedPrincipalResultList encapsulates the actual list of detached
>>>> JetspeedPrincipals and the total number of results.
>>>>
>>>> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
>>>> because paging the result set is not/poorly supported by OJB. Database
>>>> specific LookupManager implementations can be plugged in via Spring and
>>>> can handle database supported paging (like MySqls LIMIT) but there is a
>>>> default implementation that uses plain JDBC for paging the result set.
>>>> The DB platform is derived from OJB, there is no extra config parameter
>>>> to take care of.
>>>
>>> I tried to search any framework level support for the DBMS-side pagination
>> queries.
>>> OJB seems now ready to support that feature since 1.0.5. It has been added
>> with this issue: http://issues.apache.org/jira/browse/OJB-131
>>> Also, I had a look at some source codes such as PlatformOracleImpl [1],
>> PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package,
>> org.apache.ojb.broker.platforms). Each one seems to use its own platform
>> specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
>>> You could have a look at those in addLimitSql() method and addPagingSql()
>> method in each class.
>>> I think we can ask OJB team to make a release of 1.0.5 and we'd better use new
>> OJB or any other framework having same features.
>>>
>>> [1]
>> https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
>>>
>>> Kind regards,
>>>
>>> Woonsan
>>>
>>>>
>>>> I am planing to plug the JetspeedPrincipalLookupManager into the
>>>> JetspeedSecurityPersistenceManager via Spring.
>>>>
>>>> Any comments on that plan? Anything I have to be aware of?
>>>>
>>>> Thanks for any comment,
>>>> Joachim
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>>
>>
>> --
>>
>> < joachim müller
>> joachim@wemove.com
>>
>> wemove digital solutions gmbh
>> eschersheimer landstr. 5-7
>> 60322 frankfurt am main
>>
>> amtsgericht frankfurt am main, hrb 53992
>> geschäftsführer joachim müller, stefan hartmann
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
< joachim müller
joachim@wemove.com
wemove digital solutions gmbh
eschersheimer landstr. 5-7
60322 frankfurt am main
amtsgericht frankfurt am main, hrb 53992
geschäftsführer joachim müller, stefan hartmann
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Joachim,
----- Original Message ----
> From: Joachim Müller <jo...@wemove.com>
> To: jetspeed-dev@portals.apache.org
> Sent: Sat, January 16, 2010 1:04:13 PM
> Subject: Re: New User/Group/Role Management Portlet
>
> Hi Woonsan,
>
> thanks for the comments. I did check out the "upcoming" OJB 1.0.5 as
> well but the "upcoming" takes time since the 1.0.5-rc1 version
> was released at 29-Jan-2008 and the last commit on the project was on
> 31-Jan-2008. It seems OJB is a dead project.
Probably. However we need to stick to it if we're not ready to move to any other framework yet. ;-)
>
> The other option would be to wait until the JPA integration is there.
> But I think this is a major change and therefore not to be expected in
> the very near future. (I think Randy was already working on this already...)
>
I don't know if the current OpenJPA or the comming OpenJPA 2.0 supports dbms-specific-optimized pagination query options.
JPA 2.0 Specification defines pagination APIs in query interfaces though.
Also, we probably replace the current OJB by JPA in the future, but I don't know how close it would be even in the trunk. Does anybody have an idea on this?
> And last but not least I wanted to create a 2.1.4 compatible solution to
> be backported.
If we need to support 2.1.4 or 2.1.3 as well, then I think we'd better adopt the new OJB maintenance release for the pagination support. It's simply because it wouldn't require any significant changes, with transparent pagination support on every database platform.
>
> I am perfectly sure that this will be an intermediate solution for the
> trunk until the JPA implementation is there, but I think the current
> solution needs to be upgraded ASAP, because it is not suitable for
> installations with big numbers of users (no database level paging support).
Agreed.
My two cents is that we could stick to the new OJB maintenance release for that if there's any technical issues with the new OJB release.
Is anybody aware of any technical problem?
Regards,
Woonsan
>
> Regards,
> Joachim
>
>
>
> Am 15.01.2010 07:01, schrieb Woonsan Ko:
> > Hi Joachim,
> >
> > Please see my comments below.
> >
> >
> >
> > ----- Original Message ----
> >> From: Joachim Müller
> >> To: Jetspeed Developers List
> >> Sent: Wed, January 13, 2010 12:39:52 AM
> >> Subject: New User/Group/Role Management Portlet
> >>
> >> Hi,
> >>
> >> I want to create new User/Group/Role Management portlets that are easier
> >> to use/understand. The main requirements are:
> >>
> >> - easy to understand UI
> >> - simple but powerful query interface
> >> - paging for the principal results list
> >> - be able to work with 10.000+ users in terms of memory/performance
> >>
> >> To accomplish the requirements I would like to introduce a
> >> JetspeedPrincipalLookupManager with the method:
> >>
> >> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> >> queryContext);
> >>
> >> The JetspeedPrincipalQueryContext holds all possible query parameters
> >> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
> >> asscoiatedUsers, sort order, paging parameters, etc.).
> >>
> >> The JetspeedPrincipalResultList encapsulates the actual list of detached
> >> JetspeedPrincipals and the total number of results.
> >>
> >> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
> >> because paging the result set is not/poorly supported by OJB. Database
> >> specific LookupManager implementations can be plugged in via Spring and
> >> can handle database supported paging (like MySqls LIMIT) but there is a
> >> default implementation that uses plain JDBC for paging the result set.
> >> The DB platform is derived from OJB, there is no extra config parameter
> >> to take care of.
> >
> > I tried to search any framework level support for the DBMS-side pagination
> queries.
> > OJB seems now ready to support that feature since 1.0.5. It has been added
> with this issue: http://issues.apache.org/jira/browse/OJB-131
> > Also, I had a look at some source codes such as PlatformOracleImpl [1],
> PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package,
> org.apache.ojb.broker.platforms). Each one seems to use its own platform
> specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
> > You could have a look at those in addLimitSql() method and addPagingSql()
> method in each class.
> > I think we can ask OJB team to make a release of 1.0.5 and we'd better use new
> OJB or any other framework having same features.
> >
> > [1]
> https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
> >
> > Kind regards,
> >
> > Woonsan
> >
> >>
> >> I am planing to plug the JetspeedPrincipalLookupManager into the
> >> JetspeedSecurityPersistenceManager via Spring.
> >>
> >> Any comments on that plan? Anything I have to be aware of?
> >>
> >> Thanks for any comment,
> >> Joachim
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
>
> --
>
> < joachim müller
> joachim@wemove.com
>
> wemove digital solutions gmbh
> eschersheimer landstr. 5-7
> 60322 frankfurt am main
>
> amtsgericht frankfurt am main, hrb 53992
> geschäftsführer joachim müller, stefan hartmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by Joachim Müller <jo...@wemove.com>.
Hi Woonsan,
thanks for the comments. I did check out the "upcoming" OJB 1.0.5 as
well but the "upcoming" takes time since the 1.0.5-rc1 version
was released at 29-Jan-2008 and the last commit on the project was on
31-Jan-2008. It seems OJB is a dead project.
The other option would be to wait until the JPA integration is there.
But I think this is a major change and therefore not to be expected in
the very near future. (I think Randy was already working on this already...)
And last but not least I wanted to create a 2.1.4 compatible solution to
be backported.
I am perfectly sure that this will be an intermediate solution for the
trunk until the JPA implementation is there, but I think the current
solution needs to be upgraded ASAP, because it is not suitable for
installations with big numbers of users (no database level paging support).
Regards,
Joachim
Am 15.01.2010 07:01, schrieb Woonsan Ko:
> Hi Joachim,
>
> Please see my comments below.
>
>
>
> ----- Original Message ----
>> From: Joachim Müller <jo...@wemove.com>
>> To: Jetspeed Developers List <je...@portals.apache.org>
>> Sent: Wed, January 13, 2010 12:39:52 AM
>> Subject: New User/Group/Role Management Portlet
>>
>> Hi,
>>
>> I want to create new User/Group/Role Management portlets that are easier
>> to use/understand. The main requirements are:
>>
>> - easy to understand UI
>> - simple but powerful query interface
>> - paging for the principal results list
>> - be able to work with 10.000+ users in terms of memory/performance
>>
>> To accomplish the requirements I would like to introduce a
>> JetspeedPrincipalLookupManager with the method:
>>
>> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
>> queryContext);
>>
>> The JetspeedPrincipalQueryContext holds all possible query parameters
>> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
>> asscoiatedUsers, sort order, paging parameters, etc.).
>>
>> The JetspeedPrincipalResultList encapsulates the actual list of detached
>> JetspeedPrincipals and the total number of results.
>>
>> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
>> because paging the result set is not/poorly supported by OJB. Database
>> specific LookupManager implementations can be plugged in via Spring and
>> can handle database supported paging (like MySqls LIMIT) but there is a
>> default implementation that uses plain JDBC for paging the result set.
>> The DB platform is derived from OJB, there is no extra config parameter
>> to take care of.
>
> I tried to search any framework level support for the DBMS-side pagination queries.
> OJB seems now ready to support that feature since 1.0.5. It has been added with this issue: http://issues.apache.org/jira/browse/OJB-131
> Also, I had a look at some source codes such as PlatformOracleImpl [1], PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package, org.apache.ojb.broker.platforms). Each one seems to use its own platform specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
> You could have a look at those in addLimitSql() method and addPagingSql() method in each class.
> I think we can ask OJB team to make a release of 1.0.5 and we'd better use new OJB or any other framework having same features.
>
> [1] https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
>
> Kind regards,
>
> Woonsan
>
>>
>> I am planing to plug the JetspeedPrincipalLookupManager into the
>> JetspeedSecurityPersistenceManager via Spring.
>>
>> Any comments on that plan? Anything I have to be aware of?
>>
>> Thanks for any comment,
>> Joachim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
< joachim müller
joachim@wemove.com
wemove digital solutions gmbh
eschersheimer landstr. 5-7
60322 frankfurt am main
amtsgericht frankfurt am main, hrb 53992
geschäftsführer joachim müller, stefan hartmann
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: New User/Group/Role Management Portlet
Posted by Woonsan Ko <wo...@yahoo.com>.
Hi Joachim,
Please see my comments below.
----- Original Message ----
> From: Joachim Müller <jo...@wemove.com>
> To: Jetspeed Developers List <je...@portals.apache.org>
> Sent: Wed, January 13, 2010 12:39:52 AM
> Subject: New User/Group/Role Management Portlet
>
> Hi,
>
> I want to create new User/Group/Role Management portlets that are easier
> to use/understand. The main requirements are:
>
> - easy to understand UI
> - simple but powerful query interface
> - paging for the principal results list
> - be able to work with 10.000+ users in terms of memory/performance
>
> To accomplish the requirements I would like to introduce a
> JetspeedPrincipalLookupManager with the method:
>
> JetspeedPrincipalResultList getPrincipals(JetspeedPrincipalQueryContext
> queryContext);
>
> The JetspeedPrincipalQueryContext holds all possible query parameters
> (principal name, attributes, asscoiatedRoles, asscoiatedGroups,
> asscoiatedUsers, sort order, paging parameters, etc.).
>
> The JetspeedPrincipalResultList encapsulates the actual list of detached
> JetspeedPrincipals and the total number of results.
>
> The JetspeedPrincipalLookupManager will be implemented using plain JDBC
> because paging the result set is not/poorly supported by OJB. Database
> specific LookupManager implementations can be plugged in via Spring and
> can handle database supported paging (like MySqls LIMIT) but there is a
> default implementation that uses plain JDBC for paging the result set.
> The DB platform is derived from OJB, there is no extra config parameter
> to take care of.
I tried to search any framework level support for the DBMS-side pagination queries.
OJB seems now ready to support that feature since 1.0.5. It has been added with this issue: http://issues.apache.org/jira/browse/OJB-131
Also, I had a look at some source codes such as PlatformOracleImpl [1], PlatformMySQLImpl and PlatformPostgreSQLImpl (in the package, org.apache.ojb.broker.platforms). Each one seems to use its own platform specific ones: rownum/rnum for oracle, LIMIT for MySQL, etc.
You could have a look at those in addLimitSql() method and addPagingSql() method in each class.
I think we can ask OJB team to make a release of 1.0.5 and we'd better use new OJB or any other framework having same features.
[1] https://svn.eu.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
Kind regards,
Woonsan
>
> I am planing to plug the JetspeedPrincipalLookupManager into the
> JetspeedSecurityPersistenceManager via Spring.
>
> Any comments on that plan? Anything I have to be aware of?
>
> Thanks for any comment,
> Joachim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org