I have a separate machines for development and deployment. On the development machine, I have the datasources
named exactly like the deployment machine, but the URL they point to differ (cocoon.xconf).
If you run multiple cocoons in one tomcat, you can configure each cocoon.xconf differently:
tomcat
- webapps
- - cocoon-julian
- - - WEB-INF
- - - - cocoon.xconf
- - cocoon-leon
- - - WEB-INF
- - - - cocoon.xconf
each xconf with a section
<datasources>
<jdbc name="NameIsAlwaysTheSame">
<dburl>thisUrlMayDifferInTheVariousCocoons</dburl>That is with multiple cocoon instances (on one Tomcat server).
If you choose to have one cocoon, and give everyone their own mounted app in the same single cocoon, you
share your datasource, or you need to give everyone their own datasource (and thus everyone uses a differenr
name).
That's at least what I think. There may be some wizardry in the sitemap.xmap possible to rename datasources,
but I don't think so. It may be possible.
What I, however, hear you say (may be my ears) is that you want some kind of portal application for the users. Each
user (not developer) also has his/her own datasources and application. I don't think that would work. You can easily
make the app look and behave differently based on their preferences, look at the portal.
This uses settings stored in the (authentication) database (or local file)
. But datasources is *probably* not the way to go; the idea of a datasources
is easy pooling and sharing of a datasources. If everyone logs in differently anyway (need their own connection) you
can just as well store usernames and passwords for the database in the authentication db (encrypted - of course),
and use java.sql.Connection directly to create your connections. The only handy feature is that you can still load
the driver in the web.xml.
If you have like 3 classes of users, and 3 types of datasources you might, then again, wish to configure the datasources
in cocoon.xconf. That is a design issue. I think (and that's nothing more than an opinion) that personal data does
not belong in cocoon.xconf, but conceptual data (like categorized connections: user administrator bossman) can be
in cocoon.xconf.
If you still wish to pool connections you might wish to do that using your own java classes (borrowing from the
existing Avalon and Apache code - of course).
And that unique id in the URI is a good idea - but the authentication framework can do that for you. And can
provide you with session contexts which can be used in both an xsp as a Flowscript environment (and probably even more).
Leon
Julian wrote:
Hi:
Thanks all, I appreciate the input. I was thinking about using the Tomcat manager application to reload individual web-apps on the server. However, I am still unclear as to how one would mount individual workspaces while maintaining a seperation of logic and datastores b/w users. Are you guys sharing the datasource? What will keep updates to the the datasource isolated b/w web-apps? I looked further into the "Context" element of server.xml (thanks Antonio) and it seems you can map different users to seperate apps by using the org.apache.catalina.startup.UserConfig Listener (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html#User%20Web%20Applications), but this is not really a clean solution for a production environment. I imagine I can use this for a development environment, but if I put the app on the web I would want different users to have customized version of the webapp and seperate datasources as well (all transparent of course). I suppose this is a design issue? Maybe use a unique id that is placed in the URIs to the datastore and webapp contexts...
Gratefully,
Julian
*/Antonio Gallardo <[EMAIL PROTECTED]>/* wrote:
Hi:
Our development environment looks is:
The server configured with Tomcat 5.0.19 and 4 cocoon webapp inside + 1 full Cocoon install + samples for reference. You can look at it as 5 cocoon applications running on the same server.
Since the applications uses diferents blocks, each one has a particular custom build.
The workstations are using NFS to share the tomcat instalation. Developers has access to the webapp dir and work directly inside the webapp dir on Tomcat installation.
We also use a simple script to allow us to restart tomcat as the user that run tomcat. This is useful if we need to redeploy a jar file.
As each application has his own log, every developer can see what happen inside the application.
At the end of the day we make backups (cca. 200 MB) on CD-RW.
Of course another approach can be using the in server.xml to define another places to deploy the applications.
Best Regards,
Antonio Gallardo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Live simply so others may simply live.
-Ghandi
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
-William of Occam <http://hepweb.rl.ac.uk/ppUK/PhysFAQ/occam.html>
------------------------------------------------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway <http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html> - Enter today
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
