portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Müller <joac...@wemove.com>
Subject Re: New User/Group/Role Management Portlet
Date Tue, 19 Jan 2010 04:22:06 GMT
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 <joachim@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


Mime
View raw message