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 17:23:33 GMT
Hi,

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 <agallardo@agssa.net>/* 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: users-unsubscribe@cocoon.apache.org
>     For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message