portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: New User/Group/Role Management Portlet
Date Tue, 19 Jan 2010 11:41:54 GMT
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
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.



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<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 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
>>>>> 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
>>> 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

View raw message