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<[email protected]>
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
