You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/02/24 18:17:00 UTC
[RT] Cocoon Web Applications
If there is something I don't personally like about Cocoon it's the
feeling of 'monolithicity' that gives the cocoon.war file and the
problems that this creates.
Many people find a 12 Mb .war file a little too much and I perfectly
agree with them: people working 'on top' of cocoon (not inside cocoon),
would like a better way to *install* their stuff on top and not within
the war file.
The ideal scenario should be something like this:
1) install an empty cocoon (with only the core libraries it needs to
operate).
2) deploy cocoon web applications (CWA) on top.
In short: inherit the .war pattern and make Cocoon look similar to
Tomcat than to a servlet. (so, providing a solid IoC pattern of use).
- o -
I was part of the group who designed the .war concept and at that time
we greatly overlooked the concept of 'inter modularization' of .war
modules: servlet web applications were 'sealed' as applications, not
components. Interoperation of .war webapps was *not* taken into
consideration.... I believe this is the reason why there are tons of
'php' webapps and some of them interoperating (see www.horder.org) while
there are very .war applications that interoperate.
I don't want this to happen with Cocoon.
Like I stated previously, I'd like to see these .cwa archives as
'components' that must be assembled in order to provide a functionality.
This is the same pattern that avalon used: components and blocks.
Components are small-size clusters of classes that provide a single or a
small number of related services. Blocks are clusters of components that
provide a more high-level service.
Avalon components are used as-is inside Cocoon, and Cocoon itself can be
considered an Avalon Block (in fact, actually it's just an inteface away
to become one!) with Servlet API and CLI wrappers (other wrappers might
be useful in the future, like a Mailet wrapper, for example).
But the above is a code-oriented view of the architecture.
If we move into a web-oriented view, then each 'stylesheet' or
'document' can be seen as a 'transformation' component. A pipeline is
how they are connected together to operate. A cocoon webapp block can be
seen as the entire archive made with
- sitemap (xmap)
- documents (xml, stylesheets, pagesheets, images, etc..)
- cocoon components (classes)
- component configurations (xconf)
- libraries (jar, dll, so)
This RT is made to trigger discussion in the creation of:
1) an archive format (a-la .war)
2) a DTD for cwa deployment descriptors (a-la web.xml)
3) tools to create the package
4) tools to deploy the packages, check dependencies, guide installation
and configuration
The major difference between a .war archive and a .cwa archive will be
the their polymorphic nature: while a .war deployment descriptor is a
file that describes only the *internals* of the archive, a .cwa
deployment descriptor will have to include:
1) what 'behavior' the cwa component implements (indicated as a
versioned URI), similar to the java concept of classes implementing
interfaces
2) what other cwa components this component requires (if any), here the
'behavioral URI' is indicated, allowing polymorphism
Imagine a possible scenario of use:
1) you find a cool cocoon webapp to install on your site
2) you download the .cwa file
3) you deploy it on top of your cocoon, indicating where you want to
'mount' it in your web site URI space.
4) if a component that implements the same (versioned!) behavior is
already present in the system, a choice of overwriting or aborting is
given.
5) if not, the component is unpacked and installed and its dependencies
checked.
6) all the dependencies are checked, if a behavior is required by the
component but it's not found in the system, the deployer will connect to
the cocoon cwa database (hosted on xml.apache.org/cocoon/cwa or similar)
possibly using a web service and give the user choices about the
different implementations. The user is given the opportunity to install
its own implementation of that behavior.
7) when all dependencies are matched, the component is finally made
available.
But how do cwa components interoperate?
My idea is to come up with a protocol:
component[role]://path/resource
something like
<match pattern="**">
<generate type="mailbox" src="{1}"/>
<transform type="xslt" src="mail2document.xslt"/>
<transform type="xslt" src="[skin]:/document2html.xslt"/>
<serialize/>
</match>
comments?
--
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 giacomo <gi...@apache.org>.
On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
> giacomo wrote:
> >
> > On Thu, 28 Feb 2002, Stefano Mazzocchi wrote:
> >
> > > Antti Koivunen wrote:
> > > >
> > > > Stefano,
> >
> > <snip/>
> >
> > > > Thanks, I like it too. Another even more general term would be simply
> > > > 'Cocoon Module', but it might not have the same marketing value (and the
> > > > acronym would be confusing :)
> > >
> > > Hmmm, what do others think of this?
> >
> > I'd like the name "Cocoon Component" or "Cocoon Application Component"
> > or simply "Cocoon Application" because it is not focused on a given
> > technology (like Web) so it could also be for Mail as well as for
> > Commandline, etc.
>
> Hmmm, good point.
>
> What about 'Cocoon Block'? It uses the same Avalon patterns, just onto a
> different level.
As I'm in the process of writing some Avalon Blocks for my next project
so I do like it :)
> 'Cocoon Module' is the second best, even if almost everyone has a
> different opinion of what a 'module' is.
Yup. And also Module is kinda dusty (Cobol, PL/1, Modula)
>
> > > > <skip/>
> > > > >>
> > > > >>>But a package manager alone would not something that would please my
> > > > >>>search for a viable way to make cocoon web applications easily reused
> > > > >>>between different projects.
> > > > >>>
> > > > >>I agree (and would love to see that repository of Cocoon modules :)
> > > > >>
> > > > >
> > > > > Exactly and I think that in order to make sure they interoperate in a
> > > > > nice and easy way, CWC polymorphism would be way cool!
> > > >
> > > > Absolutely. Perhaps it's time to get back to the root of this thread and
> > > > start defining things in detail :)
> > >
> > > Yes, totally. Why don't you get back to my first email and comment on
> > > the technical details that I expressed there? I'm sure this will start a
> > > discussion and others might jump in.
> >
> > Which one do you mean. Your original RT from September 30 last year ;)
>
> :)
>
> > There you have showed us the hole possibilities that we could add (like
> > an Avalon Phoenix Kernel) which will be nice in the end but I'd propose
> > to go there in steps.
>
> Agreed.
>
> > 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.
>
> right
>
> > 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)
>
> right
>
> > 3. there is only one lib directory for all jars (WEB-INF/lib).
>
> exactly!
>
> > 4. You have to stop and start your servlet engine.
>
> yep, Cocoon needs an hotly extensible classloader, just like Tomcat has
> (you can hotdeploy new wars on tomcat without restarting, this should be
> possible for Cocoon as well).
>
> Ugo, sure it's possible to mount new sitemaps on top of a running
> cocoon, but not if they connect to components that are to be deployed
> with jars along with the sitemap and the other resources. This is the
> real point.
>
> > 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).
>
> Yes, we need a 'block manager', possibly with a secure web interface.
>
> > 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.
>
> No, we should leave things as back compatible as possible....hmmm, I'll
> think about it.
I know. maybe we can make it both ways.
>
> > 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.
>
> Absolutely agreed.
>
>
Giacomo
---------------------------------------------------------------------
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>.
giacomo wrote:
>
> On Thu, 28 Feb 2002, Stefano Mazzocchi wrote:
>
> > Antti Koivunen wrote:
> > >
> > > Stefano,
>
> <snip/>
>
> > > Thanks, I like it too. Another even more general term would be simply
> > > 'Cocoon Module', but it might not have the same marketing value (and the
> > > acronym would be confusing :)
> >
> > Hmmm, what do others think of this?
>
> I'd like the name "Cocoon Component" or "Cocoon Application Component"
> or simply "Cocoon Application" because it is not focused on a given
> technology (like Web) so it could also be for Mail as well as for
> Commandline, etc.
Hmmm, good point.
What about 'Cocoon Block'? It uses the same Avalon patterns, just onto a
different level.
'Cocoon Module' is the second best, even if almost everyone has a
different opinion of what a 'module' is.
> > > <skip/>
> > > >>
> > > >>>But a package manager alone would not something that would please my
> > > >>>search for a viable way to make cocoon web applications easily reused
> > > >>>between different projects.
> > > >>>
> > > >>I agree (and would love to see that repository of Cocoon modules :)
> > > >>
> > > >
> > > > Exactly and I think that in order to make sure they interoperate in a
> > > > nice and easy way, CWC polymorphism would be way cool!
> > >
> > > Absolutely. Perhaps it's time to get back to the root of this thread and
> > > start defining things in detail :)
> >
> > Yes, totally. Why don't you get back to my first email and comment on
> > the technical details that I expressed there? I'm sure this will start a
> > discussion and others might jump in.
>
> Which one do you mean. Your original RT from September 30 last year ;)
:)
> There you have showed us the hole possibilities that we could add (like
> an Avalon Phoenix Kernel) which will be nice in the end but I'd propose
> to go there in steps.
Agreed.
> 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.
right
> 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)
right
> 3. there is only one lib directory for all jars (WEB-INF/lib).
exactly!
> 4. You have to stop and start your servlet engine.
yep, Cocoon needs an hotly extensible classloader, just like Tomcat has
(you can hotdeploy new wars on tomcat without restarting, this should be
possible for Cocoon as well).
Ugo, sure it's possible to mount new sitemaps on top of a running
cocoon, but not if they connect to components that are to be deployed
with jars along with the sitemap and the other resources. This is the
real point.
> 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).
Yes, we need a 'block manager', possibly with a secure web interface.
> 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.
No, we should leave things as back compatible as possible....hmmm, I'll
think about it.
> 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.
Absolutely agreed.
--
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: 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
Re: [RT] Cocoon Web Applications
Posted by Ugo Cei <u....@cbim.it>.
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: [RT] Cocoon Web Applications
Posted by giacomo <gi...@apache.org>.
On Thu, 28 Feb 2002, Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
> >
> > Stefano,
<snip/>
> > Thanks, I like it too. Another even more general term would be simply
> > 'Cocoon Module', but it might not have the same marketing value (and the
> > acronym would be confusing :)
>
> Hmmm, what do others think of this?
I'd like the name "Cocoon Component" or "Cocoon Application Component"
or simply "Cocoon Application" because it is not focused on a given
technology (like Web) so it could also be for Mail as well as for
Commandline, etc.
> > <skip/>
> > >>
> > >>>But a package manager alone would not something that would please my
> > >>>search for a viable way to make cocoon web applications easily reused
> > >>>between different projects.
> > >>>
> > >>I agree (and would love to see that repository of Cocoon modules :)
> > >>
> > >
> > > Exactly and I think that in order to make sure they interoperate in a
> > > nice and easy way, CWC polymorphism would be way cool!
> >
> > Absolutely. Perhaps it's time to get back to the root of this thread and
> > start defining things in detail :)
>
> Yes, totally. Why don't you get back to my first email and comment on
> the technical details that I expressed there? I'm sure this will start a
> discussion and others might jump in.
Which one do you mean. Your original RT from September 30 last year ;)
There you have showed us the hole possibilities that we could add (like
an Avalon Phoenix Kernel) which will be nice in the end but I'd propose
to go there in steps.
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.
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).
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
---------------------------------------------------------------------
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>.
Antti Koivunen wrote:
>
> >> Yes, totally. Why don't you get back to my first email and comment on
> >> the technical details that I expressed there? I'm sure this will start a
> >> discussion and others might jump in.
> >
> >
> > Seems that they already did :) Perhaps you could gather the ideas under
> > a new RT 'Cocoon Blocks' (I'm sure you can do better ;)
>
> Oops, I meant to say "I'm sure you can do _it_ better" (than I could,
> with less knowledge of the Cocoon architecture and all the requirements)
>
> Even typos can cause logical errors :)
ahahaha, :) believe me, it made more sense the first one :) it triggered
me more action than the second, corrected, one.
Anyway, expect an RT on Cocoon Blocks soon enough.
--
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 Antti Koivunen <an...@users.sourceforge.net>.
>> Yes, totally. Why don't you get back to my first email and comment on
>> the technical details that I expressed there? I'm sure this will start a
>> discussion and others might jump in.
>
>
> Seems that they already did :) Perhaps you could gather the ideas under
> a new RT 'Cocoon Blocks' (I'm sure you can do better ;)
Oops, I meant to say "I'm sure you can do _it_ better" (than I could,
with less knowledge of the Cocoon architecture and all the requirements)
Even typos can cause logical errors :)
(: A ;)
---------------------------------------------------------------------
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 Antti Koivunen <an...@users.sourceforge.net>.
<skip/>
>>I wonder if this is something we should move forward on (not sure
>>myself). On one hand, it feels like an intermediate (perhaps
>>unnecessary) step to the full 'CWC' model, but on the other hand, it
>>would be relatively easy to implement (version 2.0.3 - 2.1.0) and could
>>make Cocoon more approachable. It would also provide (force) a clear
>>definition of the core fileset and purpose of each 'component' (set of
>>files) in the distribution. What do you think?
>>
>
> I'm not sure I understand your points: can you please elaborate more on
> this?
Hmmm, probably best to explain with an example. The 'distribution
descriptor' might look something like:
<distribution version="2.1" clientversion="1.0"
basedir="http://xml.apache.org/cocoon/dist">
<!-- Globals that can be later referenced. -->
<property name="src.dir" value="src"/>
<property name="lib.dir" value="lib"/>
<!-- List of all files in the distribution. -->
<files>
<f name="README.txt"/>
<f name="${src.dir}/org/apache/cocoon/SomeClass.java"/>
<f name="${lib.dir}/somelib.jar"/>
...
</files>
<!-- The core fileset. -->
<core>
<f name="*.txt"/>
<f name="${lib.dir}/core/*"/>
...
</core>
<!-- Optional modules. -->
<modules>
<module descriptor="modules/mod-a.xml"/>
<module descriptor="modules/mod-b.xml"/>
</modules>
</distribution>
and a module descriptor might look like:
<module name="Module-A" version="1.0">
<files>
<f name="${src.dir}/org/apache/cocoon/moda/**"/>
<f name="${lib.dir}/optional/dep-a.jar"/>
</files>
</module>
I hope this shows the idea. The component based architecture would allow
these type of file level dependencies. This would provide a clear
(automatically documentable) definition of the relationships between
each component in the distribution. However, even though most of the
process could probably be automated, I'd be careful not to introduce
anything that could potentially slow down the actual development.
>>The Cocoon core could essentially consist of the 'XML processing
>>controller' (in lack of a better term) and the 'CWC container'. I have
>>to say I really like where this is going :) It could open a new array of
>>possibilities for extensibility, component reuse, remote management, etc.
>>
>
> Easy, let's keep the feet on the ground :) what you are perceiving is
> the freedom that a better architecture gives you, but it's very easy to
> get carried over and loose focus, I don't want this.
I know, I know :) but we should of course pursue the ideal architecture.
>>>I like 'Cocoon Web Component', yeah, that's a good name.
>>>
>>Thanks, I like it too. Another even more general term would be simply
>>'Cocoon Module', but it might not have the same marketing value (and the
>>acronym would be confusing :)
>>
>
> Hmmm, what do others think of this?
Well, this was already taken elsewhere, but I also like 'Cocoon Block'.
>>>Exactly and I think that in order to make sure they interoperate in a
>>>nice and easy way, CWC polymorphism would be way cool!
>>>
>>Absolutely. Perhaps it's time to get back to the root of this thread and
>>start defining things in detail :)
>>
>
> Yes, totally. Why don't you get back to my first email and comment on
> the technical details that I expressed there? I'm sure this will start a
> discussion and others might jump in.
Seems that they already did :) Perhaps you could gather the ideas under
a new RT 'Cocoon Blocks' (I'm sure you can do better ;)
(: A ;)
---------------------------------------------------------------------
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>.
Antti Koivunen wrote:
>
> Stefano,
>
> It seems that we pretty much agree on everything :)
cool
> (My first mail was mostly prompted by the use of the term "Web
> Application" and the "replacement for .war" impression that I first got
> from the message, but I realize that of course wasn't the idea.)
yes, I want to 'modularize' cocoon from the user perspective, not only
from the developer's perspective (as it is today).
> See below for more...
>
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano Mazzocchi wrote:
> >>
> >>>Antti Koivunen wrote:
> >>>
> <skip/>
> >>>>
> >>>>Based on this, and other discussion on this list, I think it could be
> >>>>useful to have some kind of installation/configuration tool for Cocoon.
> >>>>It shouldn't be too difficult to implement with a clear definition of
> >>>>core libraries, optional modules and dependencies (within the same
> >>>>Cocoon distribution). At first, it could be a simple client app that
> >>>>just does the following:
> >>>>
> >>>> 1. Download a set of files describing the Cocoon distribution.
> >>>> 2. Select the desired modules (in addition to the core fileset).
> >>>> 3. Check the dependencies (file-level, within the same distribution).
> >>>> 4. Create the directory structure and download the required files.
> >>>> 5. Create a sample sitemap and xconf for the selected modules.
> >>>>
> <skip/>
> >>>
> >>Well, more of a way of increasing the modularity and internal
> >>consistency of the Cocoon distribution (as opposed to a complete package
> >>management solution).
> >>
> >
> > ok
>
> I wonder if this is something we should move forward on (not sure
> myself). On one hand, it feels like an intermediate (perhaps
> unnecessary) step to the full 'CWC' model, but on the other hand, it
> would be relatively easy to implement (version 2.0.3 - 2.1.0) and could
> make Cocoon more approachable. It would also provide (force) a clear
> definition of the core fileset and purpose of each 'component' (set of
> files) in the distribution. What do you think?
I'm not sure I understand your points: can you please elaborate more on
this?
> <skip/>
> >>>
> >>I'm all for increasing the modularity and extensibility of Cocoon, and I
> >>like e.g. the concept of "skins", but I'm not sure that "Web
> >>Application" is the right "unit" to use. I mean, it's just as likely
> >>that Cocoon is used as a part of a single webapp, and I'd also like to
> >>see the same modularity apply to other components, e.g. the likes of hsqldb.
> >>
> >
> > Of course. Modularity should be both 'vertical' (as with the 'skin'
> > approach) and 'horizontal' (as with hsqldb examples or a portal
> > application).... but I think my proposal solves both at the same time.
>
> I think so too. We just have to define all the things that the modules
> may require and expose, e.g. one might just provide a simple role, while
> another one could include a sitemap and a mount-point, etc.
>
> The Cocoon core could essentially consist of the 'XML processing
> controller' (in lack of a better term) and the 'CWC container'. I have
> to say I really like where this is going :) It could open a new array of
> possibilities for extensibility, component reuse, remote management, etc.
Easy, let's keep the feet on the ground :) what you are perceiving is
the freedom that a better architecture gives you, but it's very easy to
get carried over and loose focus, I don't want this.
> >>If CWA is defined to be "something that provides additional
> >>functionality" for the Cocoon instance, then I think it's a good idea
> >>(but perhaps better named to "Cocoon Web Component" or CWC, respectively).
> >>
> >
> > I like 'Cocoon Web Component', yeah, that's a good name.
>
> Thanks, I like it too. Another even more general term would be simply
> 'Cocoon Module', but it might not have the same marketing value (and the
> acronym would be confusing :)
Hmmm, what do others think of this?
> <skip/>
> >>
> >>>But a package manager alone would not something that would please my
> >>>search for a viable way to make cocoon web applications easily reused
> >>>between different projects.
> >>>
> >>I agree (and would love to see that repository of Cocoon modules :)
> >>
> >
> > Exactly and I think that in order to make sure they interoperate in a
> > nice and easy way, CWC polymorphism would be way cool!
>
> Absolutely. Perhaps it's time to get back to the root of this thread and
> start defining things in detail :)
Yes, totally. Why don't you get back to my first email and comment on
the technical details that I expressed there? I'm sure this will start a
discussion and others might jump in.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
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 Antti Koivunen <an...@users.sourceforge.net>.
Stefano,
It seems that we pretty much agree on everything :)
(My first mail was mostly prompted by the use of the term "Web
Application" and the "replacement for .war" impression that I first got
from the message, but I realize that of course wasn't the idea.)
See below for more...
Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
>
>>Stefano Mazzocchi wrote:
>>
>>>Antti Koivunen wrote:
>>>
<skip/>
>>>>
>>>>Based on this, and other discussion on this list, I think it could be
>>>>useful to have some kind of installation/configuration tool for Cocoon.
>>>>It shouldn't be too difficult to implement with a clear definition of
>>>>core libraries, optional modules and dependencies (within the same
>>>>Cocoon distribution). At first, it could be a simple client app that
>>>>just does the following:
>>>>
>>>> 1. Download a set of files describing the Cocoon distribution.
>>>> 2. Select the desired modules (in addition to the core fileset).
>>>> 3. Check the dependencies (file-level, within the same distribution).
>>>> 4. Create the directory structure and download the required files.
>>>> 5. Create a sample sitemap and xconf for the selected modules.
>>>>
<skip/>
>>>
>>Well, more of a way of increasing the modularity and internal
>>consistency of the Cocoon distribution (as opposed to a complete package
>>management solution).
>>
>
> ok
I wonder if this is something we should move forward on (not sure
myself). On one hand, it feels like an intermediate (perhaps
unnecessary) step to the full 'CWC' model, but on the other hand, it
would be relatively easy to implement (version 2.0.3 - 2.1.0) and could
make Cocoon more approachable. It would also provide (force) a clear
definition of the core fileset and purpose of each 'component' (set of
files) in the distribution. What do you think?
<skip/>
>>>
>>I'm all for increasing the modularity and extensibility of Cocoon, and I
>>like e.g. the concept of "skins", but I'm not sure that "Web
>>Application" is the right "unit" to use. I mean, it's just as likely
>>that Cocoon is used as a part of a single webapp, and I'd also like to
>>see the same modularity apply to other components, e.g. the likes of hsqldb.
>>
>
> Of course. Modularity should be both 'vertical' (as with the 'skin'
> approach) and 'horizontal' (as with hsqldb examples or a portal
> application).... but I think my proposal solves both at the same time.
I think so too. We just have to define all the things that the modules
may require and expose, e.g. one might just provide a simple role, while
another one could include a sitemap and a mount-point, etc.
The Cocoon core could essentially consist of the 'XML processing
controller' (in lack of a better term) and the 'CWC container'. I have
to say I really like where this is going :) It could open a new array of
possibilities for extensibility, component reuse, remote management, etc.
>>If CWA is defined to be "something that provides additional
>>functionality" for the Cocoon instance, then I think it's a good idea
>>(but perhaps better named to "Cocoon Web Component" or CWC, respectively).
>>
>
> I like 'Cocoon Web Component', yeah, that's a good name.
Thanks, I like it too. Another even more general term would be simply
'Cocoon Module', but it might not have the same marketing value (and the
acronym would be confusing :)
<skip/>
>>
>>>But a package manager alone would not something that would please my
>>>search for a viable way to make cocoon web applications easily reused
>>>between different projects.
>>>
>>I agree (and would love to see that repository of Cocoon modules :)
>>
>
> Exactly and I think that in order to make sure they interoperate in a
> nice and easy way, CWC polymorphism would be way cool!
Absolutely. Perhaps it's time to get back to the root of this thread and
start defining things in detail :)
(: A ;)
---------------------------------------------------------------------
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>.
Antti Koivunen wrote:
>
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano,
> >>
> >>I agree with the objectives you described, but I'd be careful not to
> >>turn Cocoon into a package management tool. AIU, .wars and .ears were
> >>designed to be self-contained deployable archives, and as such, are
> >>quite useful for many things, such as rolling out new versions, moving
> >>from testing to QA, etc.
> >>
> >>It's likely that many users will want to continue to prepackage their
> >>.wars (and .ears), but I agree that for Cocoon this process could be
> >>facilitated, possibly with something like 'CWA's.
> >>
> >>Based on this, and other discussion on this list, I think it could be
> >>useful to have some kind of installation/configuration tool for Cocoon.
> >>It shouldn't be too difficult to implement with a clear definition of
> >>core libraries, optional modules and dependencies (within the same
> >>Cocoon distribution). At first, it could be a simple client app that
> >>just does the following:
> >>
> >> 1. Download a set of files describing the Cocoon distribution.
> >> 2. Select the desired modules (in addition to the core fileset).
> >> 3. Check the dependencies (file-level, within the same distribution).
> >> 4. Create the directory structure and download the required files.
> >> 5. Create a sample sitemap and xconf for the selected modules.
> >>
> >>The tool could of course also be used locally and it would be relatively
> >>easy to later add support for "CWA modules". Implementing the above
> >>should also be pretty straightforward. Would this be a good first step?
> >>
> >
> > Well, yes, but that's not what I want.
> >
> > What you describe above is a sort-of apt-get for cocoon.
>
> Well, more of a way of increasing the modularity and internal
> consistency of the Cocoon distribution (as opposed to a complete package
> management solution).
ok
> > ... Sure, apt-get
> > is way cool, but it's a packaging solution, not a component model.
>
> Exactly. I meant to emphasize that .wars have their purpose and that
> packaging is different from modularity, you can have one without the
> other (although it makes little sense to have the former without the
> latter).
Agreed, but I'd rather have both, thus my reasoning.
> > What I want is polymorphic behavior of webapp modules!
> >
> > There is *no* technology in the world that gives me this for the web!
> > ASAIK, at least.
>
> I'm all for increasing the modularity and extensibility of Cocoon, and I
> like e.g. the concept of "skins", but I'm not sure that "Web
> Application" is the right "unit" to use. I mean, it's just as likely
> that Cocoon is used as a part of a single webapp, and I'd also like to
> see the same modularity apply to other components, e.g. the likes of hsqldb.
Of course. Modularity should be both 'vertical' (as with the 'skin'
approach) and 'horizontal' (as with hsqldb examples or a portal
application).... but I think my proposal solves both at the same time.
> If CWA is defined to be "something that provides additional
> functionality" for the Cocoon instance, then I think it's a good idea
> (but perhaps better named to "Cocoon Web Component" or CWC, respectively).
I like 'Cocoon Web Component', yeah, that's a good name.
> > Sure, once you have polymorphic behavior for webapp modules, you have to
> > have some sort of 'package manager' (in the apt-get sense): doing it by
> > hand is a horrible task.
> >
> > But a package manager alone would not something that would please my
> > search for a viable way to make cocoon web applications easily reused
> > between different projects.
>
> I agree (and would love to see that repository of Cocoon modules :)
Exactly and I think that in order to make sure they interoperate in a
nice and easy way, CWC polymorphism would be way cool!
--
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 Antti Koivunen <an...@users.sourceforge.net>.
Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
>
>>Stefano,
>>
>>I agree with the objectives you described, but I'd be careful not to
>>turn Cocoon into a package management tool. AIU, .wars and .ears were
>>designed to be self-contained deployable archives, and as such, are
>>quite useful for many things, such as rolling out new versions, moving
>>from testing to QA, etc.
>>
>>It's likely that many users will want to continue to prepackage their
>>.wars (and .ears), but I agree that for Cocoon this process could be
>>facilitated, possibly with something like 'CWA's.
>>
>>Based on this, and other discussion on this list, I think it could be
>>useful to have some kind of installation/configuration tool for Cocoon.
>>It shouldn't be too difficult to implement with a clear definition of
>>core libraries, optional modules and dependencies (within the same
>>Cocoon distribution). At first, it could be a simple client app that
>>just does the following:
>>
>> 1. Download a set of files describing the Cocoon distribution.
>> 2. Select the desired modules (in addition to the core fileset).
>> 3. Check the dependencies (file-level, within the same distribution).
>> 4. Create the directory structure and download the required files.
>> 5. Create a sample sitemap and xconf for the selected modules.
>>
>>The tool could of course also be used locally and it would be relatively
>>easy to later add support for "CWA modules". Implementing the above
>>should also be pretty straightforward. Would this be a good first step?
>>
>
> Well, yes, but that's not what I want.
>
> What you describe above is a sort-of apt-get for cocoon.
Well, more of a way of increasing the modularity and internal
consistency of the Cocoon distribution (as opposed to a complete package
management solution).
> ... Sure, apt-get
> is way cool, but it's a packaging solution, not a component model.
Exactly. I meant to emphasize that .wars have their purpose and that
packaging is different from modularity, you can have one without the
other (although it makes little sense to have the former without the
latter).
> What I want is polymorphic behavior of webapp modules!
>
> There is *no* technology in the world that gives me this for the web!
> ASAIK, at least.
I'm all for increasing the modularity and extensibility of Cocoon, and I
like e.g. the concept of "skins", but I'm not sure that "Web
Application" is the right "unit" to use. I mean, it's just as likely
that Cocoon is used as a part of a single webapp, and I'd also like to
see the same modularity apply to other components, e.g. the likes of hsqldb.
If CWA is defined to be "something that provides additional
functionality" for the Cocoon instance, then I think it's a good idea
(but perhaps better named to "Cocoon Web Component" or CWC, respectively).
> Sure, once you have polymorphic behavior for webapp modules, you have to
> have some sort of 'package manager' (in the apt-get sense): doing it by
> hand is a horrible task.
>
> But a package manager alone would not something that would please my
> search for a viable way to make cocoon web applications easily reused
> between different projects.
I agree (and would love to see that repository of Cocoon modules :)
(: A ;)
--
Antti Koivunen (Mr.) <an...@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
---------------------------------------------------------------------
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>.
Antti Koivunen wrote:
>
> Stefano,
>
> I agree with the objectives you described, but I'd be careful not to
> turn Cocoon into a package management tool. AIU, .wars and .ears were
> designed to be self-contained deployable archives, and as such, are
> quite useful for many things, such as rolling out new versions, moving
> from testing to QA, etc.
>
> It's likely that many users will want to continue to prepackage their
> .wars (and .ears), but I agree that for Cocoon this process could be
> facilitated, possibly with something like 'CWA's.
>
> Based on this, and other discussion on this list, I think it could be
> useful to have some kind of installation/configuration tool for Cocoon.
> It shouldn't be too difficult to implement with a clear definition of
> core libraries, optional modules and dependencies (within the same
> Cocoon distribution). At first, it could be a simple client app that
> just does the following:
>
> 1. Download a set of files describing the Cocoon distribution.
> 2. Select the desired modules (in addition to the core fileset).
> 3. Check the dependencies (file-level, within the same distribution).
> 4. Create the directory structure and download the required files.
> 5. Create a sample sitemap and xconf for the selected modules.
>
> The tool could of course also be used locally and it would be relatively
> easy to later add support for "CWA modules". Implementing the above
> should also be pretty straightforward. Would this be a good first step?
Well, yes, but that's not what I want.
What you describe above is a sort-of apt-get for cocoon. Sure, apt-get
is way cool, but it's a packaging solution, not a component model.
What I want is polymorphic behavior of webapp modules!
There is *no* technology in the world that gives me this for the web!
ASAIK, at least.
Sure, once you have polymorphic behavior for webapp modules, you have to
have some sort of 'package manager' (in the apt-get sense): doing it by
hand is a horrible task.
But a package manager alone would not something that would please my
search for a viable way to make cocoon web applications easily reused
between different projects.
--
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 Antti Koivunen <an...@users.sourceforge.net>.
Stefano,
I agree with the objectives you described, but I'd be careful not to
turn Cocoon into a package management tool. AIU, .wars and .ears were
designed to be self-contained deployable archives, and as such, are
quite useful for many things, such as rolling out new versions, moving
from testing to QA, etc.
It's likely that many users will want to continue to prepackage their
.wars (and .ears), but I agree that for Cocoon this process could be
facilitated, possibly with something like 'CWA's.
Based on this, and other discussion on this list, I think it could be
useful to have some kind of installation/configuration tool for Cocoon.
It shouldn't be too difficult to implement with a clear definition of
core libraries, optional modules and dependencies (within the same
Cocoon distribution). At first, it could be a simple client app that
just does the following:
1. Download a set of files describing the Cocoon distribution.
2. Select the desired modules (in addition to the core fileset).
3. Check the dependencies (file-level, within the same distribution).
4. Create the directory structure and download the required files.
5. Create a sample sitemap and xconf for the selected modules.
The tool could of course also be used locally and it would be relatively
easy to later add support for "CWA modules". Implementing the above
should also be pretty straightforward. Would this be a good first step?
(: A ;)
Stefano Mazzocchi wrote:
> If there is something I don't personally like about Cocoon it's the
> feeling of 'monolithicity' that gives the cocoon.war file and the
> problems that this creates.
>
> Many people find a 12 Mb .war file a little too much and I perfectly
> agree with them: people working 'on top' of cocoon (not inside cocoon),
> would like a better way to *install* their stuff on top and not within
> the war file.
>
> The ideal scenario should be something like this:
>
> 1) install an empty cocoon (with only the core libraries it needs to
> operate).
>
> 2) deploy cocoon web applications (CWA) on top.
>
> In short: inherit the .war pattern and make Cocoon look similar to
> Tomcat than to a servlet. (so, providing a solid IoC pattern of use).
>
> - o -
>
> I was part of the group who designed the .war concept and at that time
> we greatly overlooked the concept of 'inter modularization' of .war
> modules: servlet web applications were 'sealed' as applications, not
> components. Interoperation of .war webapps was *not* taken into
> consideration.... I believe this is the reason why there are tons of
> 'php' webapps and some of them interoperating (see www.horder.org) while
> there are very .war applications that interoperate.
>
> I don't want this to happen with Cocoon.
>
> Like I stated previously, I'd like to see these .cwa archives as
> 'components' that must be assembled in order to provide a functionality.
>
> This is the same pattern that avalon used: components and blocks.
> Components are small-size clusters of classes that provide a single or a
> small number of related services. Blocks are clusters of components that
> provide a more high-level service.
>
> Avalon components are used as-is inside Cocoon, and Cocoon itself can be
> considered an Avalon Block (in fact, actually it's just an inteface away
> to become one!) with Servlet API and CLI wrappers (other wrappers might
> be useful in the future, like a Mailet wrapper, for example).
>
> But the above is a code-oriented view of the architecture.
>
> If we move into a web-oriented view, then each 'stylesheet' or
> 'document' can be seen as a 'transformation' component. A pipeline is
> how they are connected together to operate. A cocoon webapp block can be
> seen as the entire archive made with
>
> - sitemap (xmap)
> - documents (xml, stylesheets, pagesheets, images, etc..)
> - cocoon components (classes)
> - component configurations (xconf)
> - libraries (jar, dll, so)
>
> This RT is made to trigger discussion in the creation of:
>
> 1) an archive format (a-la .war)
> 2) a DTD for cwa deployment descriptors (a-la web.xml)
> 3) tools to create the package
> 4) tools to deploy the packages, check dependencies, guide installation
> and configuration
>
> The major difference between a .war archive and a .cwa archive will be
> the their polymorphic nature: while a .war deployment descriptor is a
> file that describes only the *internals* of the archive, a .cwa
> deployment descriptor will have to include:
>
> 1) what 'behavior' the cwa component implements (indicated as a
> versioned URI), similar to the java concept of classes implementing
> interfaces
>
> 2) what other cwa components this component requires (if any), here the
> 'behavioral URI' is indicated, allowing polymorphism
>
> Imagine a possible scenario of use:
>
> 1) you find a cool cocoon webapp to install on your site
>
> 2) you download the .cwa file
>
> 3) you deploy it on top of your cocoon, indicating where you want to
> 'mount' it in your web site URI space.
>
> 4) if a component that implements the same (versioned!) behavior is
> already present in the system, a choice of overwriting or aborting is
> given.
>
> 5) if not, the component is unpacked and installed and its dependencies
> checked.
>
> 6) all the dependencies are checked, if a behavior is required by the
> component but it's not found in the system, the deployer will connect to
> the cocoon cwa database (hosted on xml.apache.org/cocoon/cwa or similar)
> possibly using a web service and give the user choices about the
> different implementations. The user is given the opportunity to install
> its own implementation of that behavior.
>
> 7) when all dependencies are matched, the component is finally made
> available.
>
> But how do cwa components interoperate?
>
> My idea is to come up with a protocol:
>
> component[role]://path/resource
>
> something like
>
> <match pattern="**">
> <generate type="mailbox" src="{1}"/>
> <transform type="xslt" src="mail2document.xslt"/>
> <transform type="xslt" src="[skin]:/document2html.xslt"/>
> <serialize/>
> </match>
>
> comments?
>
>
--
Antti Koivunen (Mr.) <an...@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org