cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject Re: [OT] Distributed Cocoon Collab Environment
Date Tue, 13 Apr 2004 20:17:33 GMT
Well,

I think it is a bad idea to add for 100+ users a datasource 
jdbc:somedb://someip/uniqueID in the cocoon.xconf. That
makes it large and not easily maintainable.

What I would use for a unique data source per user is forget about 
cocoon pooling, but make some static java
function which manages some pool related stuff.

This pool would be filled in the xsp or flowscript with data from the 
user authentication context.

In this example, I use the Authentication framework 
(samples/blocks/authentication-fw) which can store information like
username and password in a database (that would be a pool called 
"authentication" in cocoon.xconf - though you can
give it any way you want), write a customized authentication resource 
(this is easy - I can send you a sitemap snippet and
my authentication resource if you want) which verifies the user *and* 
loads additional data from that auth. database and
puts that in the aurthentication-context available everywhere in the 
authenticated part of the sitemap.
If you don't know what I'm talking about - it took me two days reading 
docs and testing tlo get it to work as I wanted it
to. It's possible:)

Among the data your Authenticator gets from the authentication pool is 
the username and password for that particular
connection, and if required also the database URL for that user. That 
way you can create your database URL in code
like
Connection con = DriverManager.getConnection("jdbc:mysql://" + myURL + 
"?user=" + dbUserName + "&password=" dbPasswd );
and use the connection like normal.
OR
create an unpooled connection with esql (if you use XSP):
see http://cocoon.apache.org/2.1/userdocs/xsp/esql.html for more 
information (or ask).

And what you wrote is not what I thought I suggested. I thought your 
specs said everyone their own database. You can also say
that everyone already has an account on a single database, or that every 
user have their own rows:)

I would *not* add a database pool for every user in cocoon.xconf.

It might be easier if you told a bit about the preferred language (xsp, 
java, flowscript, combination thereof) and in how far the
various users need different databases. Is it like a database for 
Accounts, a database for Personnel, a database for Sales?
Or is it that everyone has their own database?

Let me recap, as I'm expanding:
You can use the authentication framework to put data in the session.
The session stays alive over all requests (well....)
Every following request of that user using that browser has the data 
stored in the session.
That means you can write the DB URL, db Username, db Password in the 
session and use it in a page when required.
You can do that in plain java, or using the esql taglib (assuming xsp).

I hope this helps, at least a bit.
And sorry about any misunderstanding:)
Leon


Julian wrote:

> hi,
>  
> great! i agree.  I think the easiest thing is to setup multiple cocoon 
> instances so developers can reset the ServletContext so the 
> ClassLoader reloads.
>  
> - webapps
> - - cocoon-julian
> - - - WEB-INF
> - - - - cocoon.xconf
> - - cocoon-leon
> - - - WEB-INF
> - - - - cocoon.xconf
> As far as the portal is concerned, user preferences for the 
> application are not stored in the database, so I think what you are 
> saying makes sense. The last problem is the database(s)...
>  
> For the developer (in their own environment) and a user (in a 
> production environment) to have the data they manipulate isolated from 
> each other, I only see one option: Use a unique id (maybe from an 
> authentication/registry db) in the URL of the datastore to isolate the 
> data.  This way you would create seperate databases (i.e. 
> jdbc:somedb://someip/uniqueID_1, jdbc:somedb://someip/uniqueID_2, 
> etc.).  Which Leon seems to agree with, right?  Is this a standard 
> approach?  It seems (as Leon suggests) that this would be a pain to 
> setup easily in order to access the db(s) via jndi....looks li.
>  
> Kind Regards,
> Julian
>  
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th 
> <http://taxes.yahoo.com/filing.html> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message