You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <u....@cbim.it> on 2002/03/01 09:36:03 UTC
Re: [RT] Cocoon Web Applications
giacomo wrote:
> We have a procedure in our company how to build and deploy Cocoon
> Application Components 'by hand' (shure we use Ant for that). It is
> based on the sub-sitemap concept (in a sub-directory of the webapps
> context root) and the root sitemap only mounts those Applications into
> the URI space Cocoon is managing (well, the root-sitemap also defines
> the most commonly used sitemap components).
>
> Granted, this procedure show clearly the leaks:
>
> 1. You have to change the root sitemap for every new Application that
> should be deployed.
>
> 2. cocoon.xconf is not able to be structured hierachically like the
> sitemap.xmap (which would enable to have separate .roles files as well
> for configuration abbreviations)
>
> 3. there is only one lib directory for all jars (WEB-INF/lib).
>
> 4. You have to stop and start your servlet engine.
I never have to stop and restart the servlet engine when deploying a
subsitemap, using Tomcat.
> To solve these deficiencies to finally enable Stefano's vision of
> deployable Application over the net we can do:
>
> For 1: The Deploying Engine (Cocoon.java today) needs to directly use
> some kind of URI-Matcher to mount the sub-sitemap of an Application. It
> could done by dynamically add those mounts to the root sitemap when
> using the interpreted sitemap treeprocessor. there will also be a method
> of dynamically specify the deployment (i.e. looking into the webapps
> context directory for newly added Cocoon Application Component archives
> or the technologically more advanced 'net deployment' procedure).
Isn't this what the "mount" mechanism is about?
> For 2: A simple way could be to change how we do it today (cocoon.xconf
> references the sitemap.xmap file). If the sitemap references the
> cocoon.xconf it would be automatically bound into the sitemap hierarchy.
> But this is a total change of the concept we have designed it. The
> original thought was that a sitemap maintainer should not mess around
> with the cocoon.xconf file and the administrator (which is messing
> around with cocoon.xconf) should be able to state where the initial
> sitemap.xmap file is.
>
> For 3: We definitively need to change the classloader design to have
> Application specific jars located and loaded separate for each
> Application.
>
> And for 4: A good architecture on 3. will solve this as well.
>
> Comments?
>
> Giacomo
I used to think that having a single instance of Cocoon and mounting
applications in subsitemaps was the best solutions, but recently I have
changed my mind. There are two reasons for this:
1. I use Apache virtual hosts to map hostnames to subsitemaps, e.g.
www.site1.com -> /cocoon/mount/site1
www.site2.com -> /cocoon/mount/site2
Unfortunately, I have discovered that the servlet container is supposed
(according to the Servlet spec) to instantiate one webapp PER vhost.
Thus I ended having multiple instances of Cocoon, each one carrying with
itself all the components defined in cocoon.xconf and all the
subsitempas. Not very efficient IMHO.
2. The second problem is that sometimes I want to use some new feature
or need some bugfix that is available only in CVS or i a more recent
release. If I substitute some of the core JARs, I risk breaking
compatibility with all the already deployed applications in subsitempas.
So I am trying to prepare a "core" Cocoon webapp, without optional
components and without samples, just the status page to check that it is
running and use it as a template for new webapps.
If the vhost "problem" has no solution, I see no advantage in deploying
different subsitemaps under the same Cocoon instance (unless you are not
using vhosts, that is).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Convert RTF to XSL:FO
Posted by Ed <cy...@cyberglide.net>.
I use rtf2fo from www.novosoft.ru
It does what i need it to do in batch
or online.
ed
At 11:56 AM 3/1/2002 +0100, you wrote:
>Looking for some suggestions on how to convert RTF documents into XSL:FO for
>further processing into PDF. Yes I know there are several tools
>"avialable" - but I would rather hear some firsthand experience....In
>particular we are looking for tools that work well when it comes to (quite
>complex) forms in RTF.
>
>Thanks
>
>Matthew
>
>--
>Open Source Group sunShine - Lighting up e:Business
>=================================================================
>Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
>Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
> Weblogging at: http://www.need-a-cake.com
>=================================================================
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by giacomo <gi...@apache.org>.
On Fri, 1 Mar 2002, Ugo Cei wrote:
> giacomo wrote:
>
> >>>For 1: The Deploying Engine (Cocoon.java today) needs to directly use
> >>>some kind of URI-Matcher to mount the sub-sitemap of an Application. It
> >>>could done by dynamically add those mounts to the root sitemap when
> >>>using the interpreted sitemap treeprocessor. there will also be a method
> >>>of dynamically specify the deployment (i.e. looking into the webapps
> >>>context directory for newly added Cocoon Application Component archives
> >>>or the technologically more advanced 'net deployment' procedure).
> >>>
> >>Isn't this what the "mount" mechanism is about?
> >>
> >
> > I don't understand what you are asking for.
>
> I am asking: doesn't the existing mount mechanism already address your
> point?
No and yes. The mount mechanism is an element of the sitemap syntax.
What we need is something like a "deploymet mechanism" which is able to
dynamically generate
<map:match pattern="URI-a-newly-deployed-cac-will-be-mounted">
<map:mount ..../>
</map:match>
into a root-sitemap (or even a component above that) to enable
deployment of new cocoon application components on the fly and over the
net.
> > If you use Apache virtual hosts you should also use Apache
> > mod_rewrite/mod_proxy for that and your scenario is easy possible with
> > only one Cocoon instance.
>
> I am using simple redirects. Probably I should be using mod_rewrite, but
> having fought with it in the past, I am a little intimidated by its
> complexity :)
We have the following snipped in the httpd.conf for each virt host:
RewriteRule ^/theurl/(.*)$ http://tomcat:8080/cocoon/theurl/$1 [P,L]
ProxyPassReverse /theurl/ http://tomcat:8080/cocoon/admin/
this works as long as you are not doing load balancing stuff.
>
> > You simply need a test environment which reflects your production
> > environment.
>
> I do have a test environment, of course, but should a new cocoon.jar
> breaks all the existing applications,
Depends on the version ;) but we cannot garantee all versions will be
backward compatible but we will give strong attention on it as long as
possible.
> I would have to chase down the
> bugs and fix them on the test env, before going production. Like they
> say: if it ain't broke, don't fix it ;).
In fact you should do that with every new software you base your
application upon (even new versions of your preferred operating system).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: mod_rewrite mod_webapp config contribl
Posted by Greg Weinger <gw...@itmedicine.net>.
After some experiment, I wanted to add the following (and we might want
to put this in the FAQ, because I didn't see an entry there for setting
up mod_webapp):
This rewrite configuration assumes you've set up the Warp connector
correctly, (and order is VERY important) which means that your
LoadModules block ends with:
LoadModule webapp_module modules/mod_webapp.so
LoadModule rewrite_module modules/mod_rewrite.so
Your AddModues block ends like so:
AddModule mod_webapp.c
AddModule mod_rewrite.c
And these configs are at the bottom of httpd.conf:
WebAppConnection warpConnection warp localhost:8008
WebAppDeploy cocoon warpConnection /cocoon
Best,
Greg
> -----Original Message-----
> From: Akber Choudhry [mailto:akber@dyanet.com]
> Sent: Friday, March 01, 2002 1:45 PM
> To: cocoon-dev@xml.apache.org
> Subject: mod_rewrite mod_webapp config contribl
>
> On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
>
> >
> > Can you donate your mod_rewrite configurations? that would make it a
> > good example in the docs, at least.
> Here it is -
>
>
> NameVirtualHost domain.com
> <VirtualHost domain.com:80>
> ServerAdmin webmaster@domain.com
> ServerName www.domain.com
> ServerAlias domain.com
> ErrorDocument 404 /cgi-bin/errors/monitor.cgi
> ErrorDocument 500 /cgi-bin/errors/monitor.cgi
>
> # Rewrite module has to be the last module in the Apache AddModule
list
> RewriteEngine On
>
> # let apache handle
>
> RewriteRule \.(gif|jpg|png|css|txt|html|js|pdf|cab|jar|php|xml)$ - [L]
> RewriteRule ^/cgi-bin - [L]
> # my apache site monitor
> RewriteRule ^/watch-info - [L]
> RewriteRule ^/$ /cocoon/index [L,PT]
> # other servlet applications - passed through
> RewriteRule ^/main - [L]
> # everything else to cocoon
> RewriteRule ^/(.*)$ /cocooon/$1 [L,PT]
>
> DocumentRoot /home/domain.com/public
> ScriptAlias /cgi-bin/ /home/domain.com/cgi-bin/
> DirectoryIndex index.html index.jsp index.php
>
> # make sure tomcat config webapp connector only binds to 127.0.0.1
for
> security - and here we access it through the same loopback interface
> WebAppConnection warpcocoon warp localhost:9999
> WebAppDeploy cocoon warpcocoon /cocoon
> # no need for different connection of other tomcat webapp
> WebAppDeploy main warpcocoon /main
> </VirtualHost>
> >
> > different builds --
> > Please, elaborate more on this.
> >
> >
> will do, probably over the weekend
>
> --
> Akber Choudhry
> Dyanet Inc.
> http://www.dyanet.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: mod_rewrite mod_webapp config contribl
Posted by giacomo <gi...@apache.org>.
On Fri, 1 Mar 2002, Akber Choudhry wrote:
> On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
>
> >
> > Can you donate your mod_rewrite configurations? that would make it a
> > good example in the docs, at least.
> Here it is -
>
>
> NameVirtualHost domain.com
> <VirtualHost domain.com:80>
> ServerAdmin webmaster@domain.com
> ServerName www.domain.com
> ServerAlias domain.com
> ErrorDocument 404 /cgi-bin/errors/monitor.cgi
> ErrorDocument 500 /cgi-bin/errors/monitor.cgi
>
> # Rewrite module has to be the last module in the Apache AddModule list
> RewriteEngine On
>
> # let apache handle
>
> RewriteRule \.(gif|jpg|png|css|txt|html|js|pdf|cab|jar|php|xml)$ - [L]
This works as long as the URI from the browsers' view can be mapped onto
a filesystem path from the Apaches' view. And you have to deploy your
cocoon webapp on the machine running Apache if you have dedicated
machines for your tomcats (we do have this scenario).
> RewriteRule ^/cgi-bin - [L]
> # my apache site monitor
> RewriteRule ^/watch-info - [L]
> RewriteRule ^/$ /cocoon/index [L,PT]
> # other servlet applications - passed through
> RewriteRule ^/main - [L]
> # everything else to cocoon
> RewriteRule ^/(.*)$ /cocooon/$1 [L,PT]
>
> DocumentRoot /home/domain.com/public
> ScriptAlias /cgi-bin/ /home/domain.com/cgi-bin/
> DirectoryIndex index.html index.jsp index.php
>
> # make sure tomcat config webapp connector only binds to 127.0.0.1 for security - and here we access it through the same loopback interface
if it runs on the same machine
> WebAppConnection warpcocoon warp localhost:9999
> WebAppDeploy cocoon warpcocoon /cocoon
> # no need for different connection of other tomcat webapp
> WebAppDeploy main warpcocoon /main
> </VirtualHost>
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
mod_rewrite mod_webapp config contribl
Posted by Akber Choudhry <ak...@dyanet.com>.
On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
>
> Can you donate your mod_rewrite configurations? that would make it a
> good example in the docs, at least.
Here it is -
NameVirtualHost domain.com
<VirtualHost domain.com:80>
ServerAdmin webmaster@domain.com
ServerName www.domain.com
ServerAlias domain.com
ErrorDocument 404 /cgi-bin/errors/monitor.cgi
ErrorDocument 500 /cgi-bin/errors/monitor.cgi
# Rewrite module has to be the last module in the Apache AddModule list
RewriteEngine On
# let apache handle
RewriteRule \.(gif|jpg|png|css|txt|html|js|pdf|cab|jar|php|xml)$ - [L]
RewriteRule ^/cgi-bin - [L]
# my apache site monitor
RewriteRule ^/watch-info - [L]
RewriteRule ^/$ /cocoon/index [L,PT]
# other servlet applications - passed through
RewriteRule ^/main - [L]
# everything else to cocoon
RewriteRule ^/(.*)$ /cocooon/$1 [L,PT]
DocumentRoot /home/domain.com/public
ScriptAlias /cgi-bin/ /home/domain.com/cgi-bin/
DirectoryIndex index.html index.jsp index.php
# make sure tomcat config webapp connector only binds to 127.0.0.1 for security - and here we access it through the same loopback interface
WebAppConnection warpcocoon warp localhost:9999
WebAppDeploy cocoon warpcocoon /cocoon
# no need for different connection of other tomcat webapp
WebAppDeploy main warpcocoon /main
</VirtualHost>
>
> different builds --
> Please, elaborate more on this.
>
>
will do, probably over the weekend
--
Akber Choudhry
Dyanet Inc.
http://www.dyanet.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Stefano Mazzocchi <st...@apache.org>.
Akber Choudhry wrote:
>
> On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
>
> > Akber Choudhry wrote:
> > >
> > > Is there the possibliity of developer build, pro build, and enterprise
> > > build, complete with optional tomcat config files etc. and checking of
> > > java versions, xerces versions etc. during build and install. Cocoon
> > > rocks, it will become a killer!
> >
> > I don't get what you're trying to suggest, but I'm very interested in
> > knowing your thought on this.
> >
>
> With reference to build difficulties being reported on cocoon-users and
> today's posting by Nicola Ken re: castor, multiple builds should be
> considered. Let us look at the users -- developers and super-users,
> regular users who want to demonstrate a proof-of-concept with an example
> application, and enterprise development teams who, having chosen Cocoon,
> want to implement it for their project.
>
> This is what I meant by dev, pro and enterprise build. These are merely
> suggestions :) to give a better out-of-the box experience and can be
> implemented as --
> a. different builds
> b. different cocoon.xconf and sitemap.xmap files
> c. Base Cocoon + modules
> and -- d. different build.xml files
>
> Pro Build - this should have J2SDK detection, servlet API version
> detection from the directories provided by the user. Minimal cocoon.xconf
> and sitemap.xmap with an examples sub-sitemap of core examples.
> Optional packages -- hsqldb -- fo -- castor --
> (with instructions on changes to sitemap, jar placement).
> Step-by-step instructions on configuring and testing JDBC connections -
> under Websphere, Weblogic, JBOSSS connection pooling and/or Avalon/cocoon
> connection pooling. An example on using existing XML-producing
> applications. Compliance Matrix by OS/J2SDK/servlet engine vendor.
> Perhaps build bundled with Tomcat4.03LE (using tomcat rudimentary JNDI
> for JDBC and sharing the tomcat logs and config directory.
>
> Enterprise Build - more documentation, charts, slides. Multiple-topology
> deployment. EJB integration. Back-end ERP integration. Relationship to
> servlet containers. Guidelines for developing custom components. Cocoon
> wrapper development. LDAP authentication. Multiple-machine deployment.
> Different builds for each deployment environment (e.g. Websphere 4.0 .ear)
>
> I would be happy to contribute wherever asked to.
Akber,
your suggestions make perfect sense, now my suggestion is: do a clean
CVS checkout, work on your local copy to fix/cut/move/change/add stuff
as you think it appropriate for your personal taste or for what you need
in your day job.
The golden rule of OSS is: there must be an itch in order to trigger a
scratch. And an itch to make the build and installation process simple
*MUST* come from those who found problems with it.
>>From my side, I can say that I like your ideas on the different
scenarios of use so I'd be very happy to have your patches incorporated
into the repository.
OSS works because if something bugs you enough, you'll dedicate
resources to it and if something doesn't bug you enough, well, than it's
ok as it is. Where do you stand? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Akber Choudhry <ak...@dyanet.com>.
On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
> Akber Choudhry wrote:
> >
> > Is there the possibliity of developer build, pro build, and enterprise
> > build, complete with optional tomcat config files etc. and checking of
> > java versions, xerces versions etc. during build and install. Cocoon
> > rocks, it will become a killer!
>
> I don't get what you're trying to suggest, but I'm very interested in
> knowing your thought on this.
>
With reference to build difficulties being reported on cocoon-users and
today's posting by Nicola Ken re: castor, multiple builds should be
considered. Let us look at the users -- developers and super-users,
regular users who want to demonstrate a proof-of-concept with an example
application, and enterprise development teams who, having chosen Cocoon,
want to implement it for their project.
This is what I meant by dev, pro and enterprise build. These are merely
suggestions :) to give a better out-of-the box experience and can be
implemented as --
a. different builds
b. different cocoon.xconf and sitemap.xmap files
c. Base Cocoon + modules
and -- d. different build.xml files
Pro Build - this should have J2SDK detection, servlet API version
detection from the directories provided by the user. Minimal cocoon.xconf
and sitemap.xmap with an examples sub-sitemap of core examples.
Optional packages -- hsqldb -- fo -- castor --
(with instructions on changes to sitemap, jar placement).
Step-by-step instructions on configuring and testing JDBC connections -
under Websphere, Weblogic, JBOSSS connection pooling and/or Avalon/cocoon
connection pooling. An example on using existing XML-producing
applications. Compliance Matrix by OS/J2SDK/servlet engine vendor.
Perhaps build bundled with Tomcat4.03LE (using tomcat rudimentary JNDI
for JDBC and sharing the tomcat logs and config directory.
Enterprise Build - more documentation, charts, slides. Multiple-topology
deployment. EJB integration. Back-end ERP integration. Relationship to
servlet containers. Guidelines for developing custom components. Cocoon
wrapper development. LDAP authentication. Multiple-machine deployment.
Different builds for each deployment environment (e.g. Websphere 4.0 .ear)
I would be happy to contribute wherever asked to.
Regards,
Akber Choudhry
http://www.dyanet.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Stefano Mazzocchi <st...@apache.org>.
Akber Choudhry wrote:
>
> I have a production Cocoon hosting environment based on mod_rewrite and
> using the host matcher for mounting sub-sitemaps. Worked like a charm in
> the following way:
>
> 1. Vhosts are defined in Apache.
> 2. mod_rewrite is used for for :
> a. serving static files (identified by extension) directly from apache.
> b. tomcat's mod_webapp does do a perfect job yet (no pass-back to
> apache).
> c. Rewriting /* to /cocoon/* - making the presence of Cocoon
> transparent.
> 3. No Vhosts are defined in Tomcat.
> 4. Minimal main sitemap.xmap with host matcher mounting subsitemaps.
Can you donate your mod_rewrite configurations? that would make it a
good example in the docs, at least.
> Problems Faced:
> 1. JSP generator behaves strangely
> 2. java security manager - even after removing the security manager
> kludge in logger.
Please, elaborate more on this.
> Wish List for current subsitemap implementation.
> 1. Logger to split logs by sub-stiemap or vhost
yes, that's a good point.
> 2. java classes loading on re-mount - already mentioned by someone else.
absolutely.
> Some thoughts from the business battlefront:
>
> There is an "replication of function" all the way from Apache through
> Tomcat to Cocoon.
eh, this will never stop... it's simply too hard to avoid duplication on
layered architectures.
> There are a myriad possible combinations, none of which
> is bulletproof for business.
"None of which" is *way* too strong. If that was right, nobody would be
running servlets in critical environments and this is *not* the case.
> Is there the possibliity of developer build, pro build, and enterprise
> build, complete with optional tomcat config files etc. and checking of
> java versions, xerces versions etc. during build and install. Cocoon
> rocks, it will become a killer!
I don't get what you're trying to suggest, but I'm very interested in
knowing your thought on this.
> Also, where is cocoon with regards to servlet filters. A servlet filter
> implementation of Cocoon will enable business with huge investments in
> servlet/jsp apps to leverage cocoon out of the box.
Hmmm
> I mean - legacy apps
> with servlets/forwarding, working as is - producing xml consumed by cocoon
> - contributing to actions. etc.
well, I never need this functionality, but I agree that it's
interesting. Anybody wants to add a 'servlet filter' wrapper to Cocoon?
:)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> From: "Akber Choudhry" <ak...@dyanet.com>
>
> [...]
> > Some thoughts from the business battlefront:
> >
> > There is an "replication of function" all the way from Apache through
> > Tomcat to Cocoon.
>
> And a big Tomcat call stack between the VM and Cocoon ;-)
>
> IIRC someone already tried in porting Cocoon and Tomcat in Phoenix; what is
> the current state?
> Could Cocoon be faster on Phoenix instead of Tomcat?
>
> > Also, where is cocoon with regards to servlet filters. A servlet filter
> > implementation of Cocoon will enable business with huge investments in
> > servlet/jsp apps to leverage cocoon out of the box. I mean - legacy apps
> > with servlets/forwarding, working as is - producing xml consumed by cocoon
> > - contributing to actions. etc.
>
> This would mean using Cocoon as a basic XSLT processor, undermining all
> possible advantages... IMHO the other way round is much better, having
> Cocoon use the result of legacy servlets.
>
> Talking about ServletFilters, why not introduce this concept in Cocoon?
>
> For example, it might enable Cocoon to have the opportunity of gzipping
> responses even when it won't run necessarily in Tomcat, since we are
> currently relying on it for this purpose.
>
> What do you guys think of enhancing the pipelines with a Filter?
-1, servlet filters are standard (Servlet 2.3), not something that only
Tomcat provides. Adding a pre/post bytestream filter to Cocoon pipes
would just duplicate this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
From: "Akber Choudhry" <ak...@dyanet.com>
[...]
> Some thoughts from the business battlefront:
>
> There is an "replication of function" all the way from Apache through
> Tomcat to Cocoon.
And a big Tomcat call stack between the VM and Cocoon ;-)
IIRC someone already tried in porting Cocoon and Tomcat in Phoenix; what is
the current state?
Could Cocoon be faster on Phoenix instead of Tomcat?
> Also, where is cocoon with regards to servlet filters. A servlet filter
> implementation of Cocoon will enable business with huge investments in
> servlet/jsp apps to leverage cocoon out of the box. I mean - legacy apps
> with servlets/forwarding, working as is - producing xml consumed by cocoon
> - contributing to actions. etc.
This would mean using Cocoon as a basic XSLT processor, undermining all
possible advantages... IMHO the other way round is much better, having
Cocoon use the result of legacy servlets.
Talking about ServletFilters, why not introduce this concept in Cocoon?
For example, it might enable Cocoon to have the opportunity of gzipping
responses even when it won't run necessarily in Tomcat, since we are
currently relying on it for this purpose.
What do you guys think of enhancing the pipelines with a Filter?
--
Nicola Ken Barozzi barozzi@nicolaken.com
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Akber Choudhry <ak...@dyanet.com>.
I have a production Cocoon hosting environment based on mod_rewrite and
using the host matcher for mounting sub-sitemaps. Worked like a charm in
the following way:
1. Vhosts are defined in Apache.
2. mod_rewrite is used for for :
a. serving static files (identified by extension) directly from apache.
b. tomcat's mod_webapp does do a perfect job yet (no pass-back to
apache).
c. Rewriting /* to /cocoon/* - making the presence of Cocoon
transparent.
3. No Vhosts are defined in Tomcat.
4. Minimal main sitemap.xmap with host matcher mounting subsitemaps.
Problems Faced:
1. JSP generator behaves strangely
2. java security manager - even after removing the security manager
kludge in logger.
Wish List for current subsitemap implementation.
1. Logger to split logs by sub-stiemap or vhost
2. java classes loading on re-mount - already mentioned by someone else.
Some thoughts from the business battlefront:
There is an "replication of function" all the way from Apache through
Tomcat to Cocoon. There are a myriad possible combinations, none of which
is bulletproof for business.
Is there the possibliity of developer build, pro build, and enterprise
build, complete with optional tomcat config files etc. and checking of
java versions, xerces versions etc. during build and install. Cocoon
rocks, it will become a killer!
Also, where is cocoon with regards to servlet filters. A servlet filter
implementation of Cocoon will enable business with huge investments in
servlet/jsp apps to leverage cocoon out of the box. I mean - legacy apps
with servlets/forwarding, working as is - producing xml consumed by cocoon
- contributing to actions. etc.
Regards,
Akber
On Fri, 1 Mar 2002, Ugo Cei wrote:
>
> I am asking: doesn't the existing mount mechanism already address your
> point?
>
>
> > If you use Apache virtual hosts you should also use Apache
> > mod_rewrite/mod_proxy for that and your scenario is easy possible with
> > only one Cocoon instance.
>
> I am using simple redirects. Probably I should be using mod_rewrite, but
> having fought with it in the past, I am a little intimidated by its
> complexity :)
>
--
Akber Choudhry
Dyanet Inc.
http://www.dyanet.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Web Applications
Posted by Ugo Cei <u....@cbim.it>.
giacomo wrote:
>>>For 1: The Deploying Engine (Cocoon.java today) needs to directly use
>>>some kind of URI-Matcher to mount the sub-sitemap of an Application. It
>>>could done by dynamically add those mounts to the root sitemap when
>>>using the interpreted sitemap treeprocessor. there will also be a method
>>>of dynamically specify the deployment (i.e. looking into the webapps
>>>context directory for newly added Cocoon Application Component archives
>>>or the technologically more advanced 'net deployment' procedure).
>>>
>>Isn't this what the "mount" mechanism is about?
>>
>
> I don't understand what you are asking for.
I am asking: doesn't the existing mount mechanism already address your
point?
> If you use Apache virtual hosts you should also use Apache
> mod_rewrite/mod_proxy for that and your scenario is easy possible with
> only one Cocoon instance.
I am using simple redirects. Probably I should be using mod_rewrite, but
having fought with it in the past, I am a little intimidated by its
complexity :)
> You simply need a test environment which reflects your production
> environment.
I do have a test environment, of course, but should a new cocoon.jar
breaks all the existing applications, I would have to chase down the
bugs and fix them on the test env, before going production. Like they
say: if it ain't broke, don't fix it ;).
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Convert RTF to XSL:FO
Posted by Bartomeu Adrover <to...@uib.es>.
See this URL:
http://www.novosoft-us.com/ns2b.nsf/w1/RTF2FO
http://www-106.ibm.com/developerworks/xml/library/x-tiprtf/
Matthew Langham wrote:
> Looking for some suggestions on how to convert RTF documents into XSL:FO for
> further processing into PDF. Yes I know there are several tools
> "avialable" - but I would rather hear some firsthand experience....In
> particular we are looking for tools that work well when it comes to (quite
> complex) forms in RTF.
>
> Thanks
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
> Weblogging at: http://www.need-a-cake.com
> =================================================================
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
Re: Convert RTF to XSL:FO
Posted by Bartomeu Adrover <to...@uib.es>.
See this URL:
http://www.novosoft-us.com/ns2b.nsf/w1/RTF2FO
http://www-106.ibm.com/developerworks/xml/library/x-tiprtf/
Matthew Langham wrote:
> Looking for some suggestions on how to convert RTF documents into XSL:FO for
> further processing into PDF. Yes I know there are several tools
> "avialable" - but I would rather hear some firsthand experience....In
> particular we are looking for tools that work well when it comes to (quite
> complex) forms in RTF.
>
> Thanks
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
> Weblogging at: http://www.need-a-cake.com
> =================================================================
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
Convert RTF to XSL:FO
Posted by Matthew Langham <ml...@s-und-n.de>.
Looking for some suggestions on how to convert RTF documents into XSL:FO for
further processing into PDF. Yes I know there are several tools
"avialable" - but I would rather hear some firsthand experience....In
particular we are looking for tools that work well when it comes to (quite
complex) forms in RTF.
Thanks
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Convert RTF to XSL:FO
Posted by Matthew Langham <ml...@s-und-n.de>.
Looking for some suggestions on how to convert RTF documents into XSL:FO for
further processing into PDF. Yes I know there are several tools
"avialable" - but I would rather hear some firsthand experience....In
particular we are looking for tools that work well when it comes to (quite
complex) forms in RTF.
Thanks
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: [RT] Cocoon Web Applications
Posted by giacomo <gi...@apache.org>.
On Fri, 1 Mar 2002, Ugo Cei wrote:
> giacomo wrote:
>
> > We have a procedure in our company how to build and deploy Cocoon
> > Application Components 'by hand' (shure we use Ant for that). It is
> > based on the sub-sitemap concept (in a sub-directory of the webapps
> > context root) and the root sitemap only mounts those Applications into
> > the URI space Cocoon is managing (well, the root-sitemap also defines
> > the most commonly used sitemap components).
> >
> > Granted, this procedure show clearly the leaks:
> >
> > 1. You have to change the root sitemap for every new Application that
> > should be deployed.
> >
> > 2. cocoon.xconf is not able to be structured hierachically like the
> > sitemap.xmap (which would enable to have separate .roles files as well
> > for configuration abbreviations)
> >
> > 3. there is only one lib directory for all jars (WEB-INF/lib).
> >
> > 4. You have to stop and start your servlet engine.
>
> I never have to stop and restart the servlet engine when deploying a
> subsitemap, using Tomcat.
As long as no java classes are deployed, yes. But as soon as you have to
deploy additional classes you go into trouble.
>
> > To solve these deficiencies to finally enable Stefano's vision of
> > deployable Application over the net we can do:
> >
> > For 1: The Deploying Engine (Cocoon.java today) needs to directly use
> > some kind of URI-Matcher to mount the sub-sitemap of an Application. It
> > could done by dynamically add those mounts to the root sitemap when
> > using the interpreted sitemap treeprocessor. there will also be a method
> > of dynamically specify the deployment (i.e. looking into the webapps
> > context directory for newly added Cocoon Application Component archives
> > or the technologically more advanced 'net deployment' procedure).
>
> Isn't this what the "mount" mechanism is about?
I don't understand what you are asking for.
>
> > For 2: A simple way could be to change how we do it today (cocoon.xconf
> > references the sitemap.xmap file). If the sitemap references the
> > cocoon.xconf it would be automatically bound into the sitemap hierarchy.
> > But this is a total change of the concept we have designed it. The
> > original thought was that a sitemap maintainer should not mess around
> > with the cocoon.xconf file and the administrator (which is messing
> > around with cocoon.xconf) should be able to state where the initial
> > sitemap.xmap file is.
> >
> > For 3: We definitively need to change the classloader design to have
> > Application specific jars located and loaded separate for each
> > Application.
> >
> > And for 4: A good architecture on 3. will solve this as well.
> >
> > Comments?
> >
> > Giacomo
>
> I used to think that having a single instance of Cocoon and mounting
> applications in subsitemaps was the best solutions, but recently I have
> changed my mind. There are two reasons for this:
>
> 1. I use Apache virtual hosts to map hostnames to subsitemaps, e.g.
>
> www.site1.com -> /cocoon/mount/site1
> www.site2.com -> /cocoon/mount/site2
>
> Unfortunately, I have discovered that the servlet container is supposed
> (according to the Servlet spec) to instantiate one webapp PER vhost.
> Thus I ended having multiple instances of Cocoon, each one carrying with
> itself all the components defined in cocoon.xconf and all the
> subsitempas. Not very efficient IMHO.
If you use Apache virtual hosts you should also use Apache
mod_rewrite/mod_proxy for that and your scenario is easy possible with
only one Cocoon instance.
> 2. The second problem is that sometimes I want to use some new feature
> or need some bugfix that is available only in CVS or i a more recent
> release. If I substitute some of the core JARs, I risk breaking
> compatibility with all the already deployed applications in subsitempas.
You simply need a test environment which reflects your production
environment.
> So I am trying to prepare a "core" Cocoon webapp, without optional
> components and without samples, just the status page to check that it is
> running and use it as a template for new webapps.
>
> If the vhost "problem" has no solution, I see no advantage in deploying
> different subsitemaps under the same Cocoon instance (unless you are not
> using vhosts, that is).
See above.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org