On Wednesday, January 7, 2004, at 08:04 AM, Paul Mansfield wrote:
On Fri, 2004-01-02 at 14:58, Paul Mansfield wrote:Jetspeed security is meant to be pluggable.Platform: redhat7.3 on intel Software: jetspeed1.4 release JDK: j2sdk 1.4.2_01
Hi,
I'm sorry if this is a dumb question, but I am trying to figure out how
JLoginUser works; I have an external user database from which I want to
pull passwords, but keep the rest of the jetspeed authentication
database the same (long story :-(
so, I have copied and extended JLoginUser, and note that it calls JetspeedSecurity.login which is a wrapper round JetspeedAuthentication.login which is a wrapper round getService().login
I am wondering which getService() it is calling? I have tried to follow
various classpaths and not struck gold - there are many places where
getService function is provided.
I got an answer, but I think I didn't explain myself properly (I realise
getService is a function in the same file), what I meant was where does
getService get the service from?
(getService -> TurbineAuthentication -> JetspeedUserManagement -> getService -> getUser -> TurbineUserManagement-> TurbineUserPeer.doSelectusers)
the javadoc for JetspeedAuthentication is pointless
http://jakarta.apache.org/jetspeed/api/org/apache/jetspeed/services/ JetspeedAuthentication.html#getService()
I've achieved what I want to, i.e. tapping in to the login scheme, but I'd still like to understand the program flow... arcane as it is.
<rant>Seems to me that it'd be hard to make it more complicated, considering all it really does it check user/pass against the DB, then populate a User object and store it in the session. I counted at least 12 levels of function calling, easy!
There are interfaces defined, and pluggable implementations.
The JetspeedAuthentication class is a static accessor.
Its a little abstraction to save you from using factories or service managers.
I've never liked static accessors since they don't implement an interface, but just mirror and wrapper it.
But they are commonly used in Java, especially at Jetspeed.
Jetspeed is an open source project that is used by lots of people.
If we just had one security service, then it wouldn't accomodate all the users who have their own security back ends.
So this is an abstraction to keep people from hacking away at the code and coupling security details to the portal implementation.
It also has some history in that Jetspeed was coupled to Turbine in previous versions.
In Jetspeed-2 I believe we are doing a better job of separating user preferences and security, although it remains to be seen
:-)And then there's the matter of the code in the package com.workingdogs.village which just magically appears and seems unreferenced in any of the main jetspeed documentation! </rant> I feel better for that :-)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
